Hacker News Reader

Comment by mahmud | Hacker News Reader

There were already open source MVC web frameworks and an army of .net developers who could have collaborated to make them great but nothing much happened.

He is lamenting that the .NET community didn't embrace the pioneering MVC frameworks from the OS community, but waited for Microsoft to deliver its own "blessed" framework.

Here is what he is forgetting: Economics. A good chunk of .NET developers are not using the system for the love of hacking. No. These people want to learn marketable skills and get/keep jobs. Whatever MS pushes out is what the market will buy, and hire for. What do you think killed Borland? Certainly not the lack of excellent quality products. Rather, their incompatibility with Microsoft. Even if your engineering is superior to Microsoft's, you can't afford to break rank, since the market will not follow your lead.

I went to a D.C. area meeting of early .NET adopters, a group of hardcore MS-specialists working for gur'ment. One of the organizers had a fat .NET book on the table, which he slapped with his palm three times and said: "Gentlemen, this is where the money is at". You could have taken me to a brothel afterwards and wouldn't have felt dirtier.

.NET is nice and you can do pretty things with it, but corporate platforms are first and foremost careers and cash-cows for people. The broke mofos are out there hacking on GHC and SBCL.

View on HN

I agree, but would add this.

Microsoft's (development) tools have never had any underlying principles other than: enabling people with minimal knowledge to get stuff done.

Thinking back through MFC, COM, VB v1-6, Access, SharePoint, WebForms and ADO.NET, none of them were characterised by any particular architectural purity or design aesthetic. But they enabled a generation of corporate developers to hack stuff together quickly (I know MFC and COM aren't all that easy but they were easier than just using the WinAPI). Which is why businesses liked the Microsoft stack and hence 9-5 developers flock to them.

What's interesting is that in recent years Microsoft has been infiltrated by other schools of thought. It's like there's a three way war going on. On the one hand there are VB.NET people using WebForms, EntityFramework, VSS and SharePoint to hack together stuff that will be thrown away in 2 years. The TFS, SQL Server, BizTalk and Dynamics people want to bring in some enterprise style rigour to the whole thing. While the C#, Linq, MVC crowd are trying to keep everything loose and open.

I doubt this is any kind of conspiracy to retain mindshare. It's just that Microsoft got big and Bill Gates started stepping back, so it lost much of it's direction.

I sense a real but rarely articulated confusion among the 9-5 developers about all this new stuff. There are 3x the number of frameworks and tools coming out of Microsoft these days, which ones will all the enterprise recruiters be looking for in 2 years? Nobody knows.

This. Right now, as a .NET developer myself, it is impossible to keep up with all the new frameworks that Microsoft are releasing.

Hint: you don't need to. Use what works for you.

I disagree. Or at least, you will cause problems for other people. One of my coworkers was delivered a Windows app by a third party - it was written using MFC. I said, "Seriously? In 2010, MFC? MFC was bad even before it became obsolete." My coworker said, "They used it once before and decided it works for them, so that's what they use."

Here's the thing: part of being a developer is keeping up to date. If you find one thing that works for you and don't ever update you are not doing your job.

That's great in theory but once an application becomes big and settled it is usually too big to just 'upgrade'. Upgrading becomes a massive time sink and when there's other deadlines pressing for stuff that your clients will actually notice then upgrading won't happen. Ballmer wants to release a new VS every 18 months. Just skip every other major release and save yourself 1/2 the pain and effort.

Why did it matter what it was written in, if it met the spec?

Learning all the intricacies of a framework takes a lot of time. Once a time, I was all for learning new things, but guess what: I discovered that old tools still delivered.

Sometimes the less dependencies factor matters too. Having to quickly develop a diagnostic application for users to download, a couple of years ago, guess what I chose: Visual Basic 6. Right, that ancient tool. No matter what, the application was easy to develop and the executable was a few kilobytes, with no requirements other than Windows 2000 SP4.

There are definitely limits. I'm not suggesting you use a 20 year old technology like MFC. However, using .NET 3.5 instead of 4.0? Just fine.

> ...hack together stuff that will be thrown away in 2 years

Hah! Just like those all those VB6 apps that have been thrown away?!

So true, but I think he meant "hack stuff together with the intention it will be thrown away in 2 years"

More like "hack stuff together because if we don't get more business quickly we won't be around in 2 years anyway"

Well, if I may, even more like "hacking stuff together that SHOULD be thrown away within two years but never is".

Maybe he meant "should have been thrown away".

I lead a small .net shop up until 2005, when MS decided that integrated unit testing was only going to be available in their Team Edition, which was $1,500 per seat. They later retracted, but we were already drinking python and ruby kool-aide and never looked back.

Although I really enjoyed C#, everything else about the community and ecosystem will eventually be a killjoy if you value your work over your resume.

I agree, C# is aweesome as a programming language. With Mono, an open source implmentation of .NET framework, it virtually runs cross all platform, even supports iPhone apps with MonoTouch.

Not only that, if you are a startup that wants to do b2b and you want to sell a product in to that market that will have a tight connection to stuff your clients already run you will be required to use .NET by your customers. Unless you like uphill battles that's the way you'll go eventually.

It sucks, but it is the reality of the business environment, web side stuff that is abstracted through some HTTP interface you can build in whatever you please but good luck trying to sneak your locally hosted rails app past the Microsoft only mentality prevalent in plenty of businesses.

Customers will not worry about "alien" technologies, unless you sell the latter as such. This is a basic sales principle.

Don't ever say you develop applications in Clojure, just say you develop in Java. Clojure is just a Jar, isn't it? Then you are just using a Java library, aren't you?

Prototypes usually end up in production, don't they? Then develop such prototypes in an agile language and just make them follow their destiny.

What are you doing around Hacker News, if you aren't able to hack the system?

EDIT: However, you should also understand when your language of choice just doesn't fit a gray-suited environment, and indeed I think Ruby doesn't. Python does.

> Don't ever say you develop applications in Clojure, just say you develop in Java.

That would be lying though, and it could get you in to a whole pile of hot water. Such 'technical tricks' may work a few times but eventually you'll have a real problem.

It's a matter of semantics. "A Java application" is perfectly honest. Just like when someone says "a native application" it says nothing about if it was actually written in OCaml.

Until the time that HR hires a person to collaborate on your project with 'java' experience and it turns out you wrote your code in clojure.

Stuff like that tends to have consequences, especially when there are contracts and liabilities involved.

Doesn't HR list frameworks along with languages? Is JDK knowledge alone enough to be employed anywhere?

We used to say that Tcl/Tk was a C library with a very complex configuration file ;-)

Excellent!

I've only been on one project where HR was so far divorced from the team executing on a project to hire candidates without us vetting them, and it was (unsurprisingly) a complete disaster.

Also, if you're hiring programmers who can't pick up a new language to work on your project, you're doing it wrong. Most of the capable folks I've worked with loved learning new tech; the problem is usually keeping them from jumping onto a new platform for every project.

You could quote Greenspun's Tenth Rule of Programming, and say therefor you skipped the error-prone process of increasing complexity-building.

I personally don't think that will be lying. I built a Java app that sets up the environment, starts Rhino and executes the app from there. The Rhino then make calls into Java classes for DB, file access and low level stuff only.

What do I call that solution? "Developed in Java". Here Rhino is to Java what JavaScript is to a HTML web site.

I think the safe way, if you want to follow that policy, is to say you develop for the JRE or for the JVM. Neither of these are lies, but they keep with the original idea of keeping peoples focus on "Java".

You are correct, that's the right way out.

JRE and JVM are technical terms. Unless you are talking to techies, I think "Java technology" and/or "Java platform" are a better choice.

I understand your suspicions: switching perspective is something techies have a difficult time with. Is Arc a language or is it a bunch of macros on top of MzScheme? It depends on how you see it.

Clojure is 100% compatible with Java, both ways in a straightforward manner, so you can easily argue that it's still Java. That's been the smartest design decision ever by its designer.

You have to understand whether your clients are interested either in leveraging the Java technology or employing code-drones. In the former case, Clojure will be fine; in the latter one it will not.

Popular wisdom teaches that most people remember the result, not the way you got it. If you use Clojure and succeed, you'll have your own way.

And my own experience concurs with lelele.

Although it bears more truth than you might think. As of Clojure 1.2, you can implement Java types from Clojure and you could build a plain old Java interface to the system if you needed to. And you'll likely be making use of many standard/community Java libraries.

What makes you say Python is more appropriate for greysuits? Ruby and Python seem very much alike to me.

Google makes him say it ;)

Yeah, Google, for the most part. You are not using an agile language, you are using some of the technology Google relies on, aren't you? ;-)

Google, and beyond it. You could easily have a case for Python: Nokia has made it available for Symbian, Microsoft endorses it via ActiveState, and so on.

My friends, if we want to be effective entrepreneurs, we must learn how to repackage things in a way customers will find attractive. A language can be just a technology, a framework, an application, and so on... whatever concerns your customers. There is no point in being strict about terminology, unless you are selling to savvy techies.

I'm sorry, but I don't agree. There is no reason why my customers need to know in what language the solution is developed in.

Besides, Ruby powers many highly visible websites and web apps. If I'd be losing a sale because I develop in Ruby and NOT Python, chances are I don't want that sale in the first place.

> There is no reason why my customers need to know in what language the solution is developed in.

Business continuity.

Business continuity applies only if we're talking about Java vs Ruby/Python/etc.

If the choice is between Ruby and Python and Clojure and any of the "esoteric" languages as far as enterprises are concerned, that's a red herring.

Let me explain better: Google does not stop at using Python, it embraces and backs it. And every grey suit knows Google.

And any grey suit that deals with the web knows about YellowPages.com which is a Rails site, as is newyorkjets.com.

Google is a compelling argument, no doubt, but if the biz dudes are open to switching from a "traditional" language/framework such as Java/J2EE or .Net, there are other "established" players that use Ruby.

Please don't take this as defending Ruby, the best tool for the job should win out. If the team proposing Python is well-versed in Python, that's what they should go with. But saying that Python is a better bet than Ruby, because Google embraces it is a bit of a strawman.

I don't know what your business is, but if it's consulting or custom development, then you may be wrong. It matters very much to me if I buy something from you that is written in some esoteric language that only a few people can develop for.

Obscure languages are a form of vendor lock-in, in that sense.

if you're developing SAAS or something, then I'm sure you're right, but that argument doesn't apply to everybody.

> Microsoft endorses it via ActiveState

Microsoft has IronPython, and I'm not aware of any existing endorsement of ActivePython from AS. There used to be some partnership or agreement between the two around Python.NET, but that project has been gone for a while now.

In a nutshell: Python actually runs well on Windows, which isn't something you can really say about MRI. (JRuby, maybe, but that brings its own set of issues.)

Linux may have gained real acceptance as a server OS, but businesses overwhelmingly still prefer Windows on the desktop.

When I was at my last company we encountered many a client which considered Java the "alien technology". I remember particularly one of the five largest banks in the world absolutely would not allow the JVM in their data center even if it was on our box. (This was the type of place where it took about a month and 3 or 4 signatures to get a port opened in the local network).

This is completely true and exactly the place I am stuck at. I have a product with major parts in RoR, that the business end user loves but the IT just won't let through. I have to now learn asp.net mvc and port everything over to it. I dread going through that.

"Not only that, if you are a startup that wants to do b2b and you want to sell a product in to that market that will have a tight connection to stuff your clients already run you will be required to use .NET by your customers. Unless you like uphill battles that's the way you'll go eventually."

It's an uphill battle, but it's not impossible. My last job involved me writing Python for insurance companies. Yeah, there's always someone who won't accept anything that isn't written in .net or Java. But generally speaking, it's only a select few on your customers' team that will even know the difference. For the most part, businesses do actually focus on what's best for their bottom line instead of framework ideology.

Actually, quite a few Haskell folks work for Microsoft Research. So it's more like the well-paid Microsoft employees are out there hacking on GHC.

The broke mofos are the ones that are working on all that .NET stuff. Working for the government as a low-level programmer is not where the money is at.

And there's too much money in consulting for the government as a low-level programmer.

  > Actually, quite a few Haskell folks work for Microsoft Research

What is up with that, anyway? Three of the most important people in Haskell -- the originators of the language and primary developers of GHC, and the foremost researchers in functional programming as I've experienced it who aren't employed by universities, Galois or wherever the fuck okmij works -- are employed by Microsoft Research [0]

Seems like a very odd place for them to be. Microsoft has absolutely no official relationship with Haskell, but it is the closest thing Haskell has to a patron.

I suppose bits of their work are trickling down into C#/LINQ (and VB) at as fast a pace as the ecosystem can absorb it, and it would be unthinkable, inappropriate, and probably disastrous in sociologically interesting ways, for Microsoft to try to push direct Haskell on conservative enterprise. I suppose "they" view it as an obscure research tool, by and for the top talent they retain, granted apparent freedom in their research, to keep a strategic reserve of deep magic. It's more likely that "they" don't think of Haskell at all.

-----

Also, while I don't think this strange relationship could be credibly attributed to any calculation of PR or prestige, I'll admit that noticing a sizeable chunk of the best stuff I've read in the field is written by known Microsoft employees has done as much to salve my personal opinion of the brand as their fall from threatening malevolence. It would be interesting to see what it would look like for Microsoft to officially recognize Haskell.

  [0]  http://research.microsoft.com/en-us/people/simonpj/
       http://research.microsoft.com/en-us/people/simonmar/
       http://research.microsoft.com/en-us/um/people/emeijer/

There's a thing called F# that you should read more about.

Borland was (almost) killed by its own stupidity. Their RAD tools were miles ahead of anything that MS had, but they got buggier and buggier with each version and their C++ compiler had and still has poor standards compliance.

I felt like I had taken a step back productivity-wise with VC++6, but it was solid compared to BCB.

There's a special place reserved in Hell for the management of Borland, right next to the management of Commodore

A large part of their demise was due to their constantly pursuing the enterprise market (they even changed their name to Inprise for a few years) where they were largely ignored and unwanted, while ignoring the indie devs and smaller shops who loved them.

In the end their developer tools went from best in class (by a very large margin) to an embarrassing copy of Visual Studio, but not quite as good and a hell of a lot more expensive.

Kylix was a bold move though, and could have been something good (it wasn't). For anyone interested, Lazarus is still going; it's a cross platform open source ide heavily inspired by Delphi (version <= 7) http://sourceforge.net/projects/lazarus/files/

I loved and used Turbo Pascal since the 3.0 days - 5.5 was probably my favourite, while 6.0 was real stable (bit bit bigger). Then I started learning Turbo C at the same time (was it 3.0), and TVision, Delphi for Windows.

Really cool products, and then Microsoft hired the guy from Borland that was responsible for the Forms Editing and other things in the IDE, and Borland changed their trademarks from the cool Delphi/Turbo/Borland to stupid names like Inprise/Kylix/etc.

The Turbo Pascal 3.00 was the smallest IDE ever in the world - 30kb of compiler, editor and libraries :)

Yes, Turbo Pascal was one of the most underrated languages ever. Blisteringly fast to run and way faster than C to compile. Clean simple language, native strings (yay!), no need to worry about memory management, pointers etc.

Built some pretty good stuff with Delphi, and I think sometimes that there's many cases where Delphi 7 is still one of the most productive desktop development packages of all time, even when compared to the latest Visual Studio.

and to those who doubt me - well, I like my rose tinted glasses, and I'm keeping them on :P

Why making money with programming makes you feel dirty?

If I already have a full-time job, and I just want to hack around as a hobby in my spare time, I don't want the language features and runtime to be tied up in the same (probably more) red tape and politicking I have to deal with at my day job. I just want to relax and hack, and if there's money involved, that's a lot less likely to be enjoyable.

The reality is that any reasonably complex endeavour will suffer from this, OSS languages included.

Then make it enjoyable: the last bit of code I hacked was "for profit" but I told the guy who wanted it to just pay me with a bottle of Patron.

He gets the code he wants, I get drunk on good tequila. What's not to love :-)

How well do you code? I know of a few startups that will happily send you to AA.

Ha! Thanks, that made my morning :-)

Seriously though, he was willing to pay me, but I wasn't comfortable taking money for something I had zero experience with (this was my first time using a Web API). And I could tell he didn't want to feel like he was ripping me off by getting my work (all 45 minutes of it) for free, so we met in the middle and both parties were happy.

It was Microsoft's answer to Java, with hindsight 20/20. I wanted to see their take on portable bytecode, JIT techniques, security, distributed computing, performance, etc. Nearly everybody there was burned by MS's short attention span when it comes to system libraries (OLE, COM, DCOM, DCOM+ for one, and the mess that is data-access libraries, OLE-DB,MDAC, ODBC, ADO, Jet, etc.)

We wanted closure, at least I knew I did. Was barely 20 and had my first serious application. Hundreds of MFC files, elaborate Win32 API integration, MS Office integration and a whole lotta crap. They fucked me over seriously bad, and I have already sunk in a year and a half of my time, skipping classes just to make it. Everytime I implemented a subsystem a new memo would come out on MSDN Magazine telling me to use a component bundled with Office for that, or tie my app into the latest IE release, or "just" use ActiveX.

I fucking wanted an answer. Instead, the fat guy they paid to talk to us said we could all get highly paying jobs if we only learned this new, new thing.

I left that mess for good. First to Perl, then Lisp. Never going back to the API carrots on a stick thing.

Part of the "Microsoft Tax" is that there is always a new new thing - when it comes to Microsoft selling products their biggest competitor is installed versions of their existing products not other vendors.

Yep. That's why I bailed back in '99. You needed an MSDN subscription just so your apps could tread water.

Phone rings "Hi, we upgraded our NT server and now your software is broken".

Many hours later "Oh MS changed the DB connection pooling to OFF"

Me: Hmm, this Personal Home Page things looks ok, I'll give that a try.

And as horrible as PHP is, it behaves itself.

I don't see how this is any worse than trying to keep up with the latest version of some OSS library. Whether it's MS that's revving or open-source developers, changes happen, and if it's a breaking change in a shared library, sometimes you get hurt.

Just yesterday there was a "goodbye python" article posted here, that blamed the fact that so many Linux installations have old installations of python, and so many things are broken when modules in the installation get updates.

Myopic viewpoints about code longevity tend to be driven by people that never worked on a project for more than 2 years. Few companies have business models that allow them to avoid the mess. It's not a problem for throw away projects or startups though.

The same PHP code has followed me round since 1999. From FreeBSD 4 to Linux to OpenBSD to FreeBSD 6 (but in a VM running on Linux).

Early on in my career I was given a codebase that adhered to every lesson in How To Write Unmaintainable Code. I can't thank fate enough.

I see what you're saying but upgrading an OSS library is usually undertaken by somebody that thinks beforehand "I wonder if upgrading this will have any implications" whereas clicking "Express" on update.windows.com is billed as pain free, just like all things point and click.

Plus I had followed the advice in MSDN concerning connection pooling which was a registry setting for ODBC NOT part of the framework I was using (VBscript in ASP). Responsibilty for pooling was pushed into the framework.

The goodbye python article was about assumptions one could make about what would be available before one's code arrived. I bet php3 code still runs just fine.

You shouldn't be hitting 'express' on windows update on a live server just as you shouldn't be running 'update world' on a live linux server

Security updates and product updates are mixed on Windows (or were I don't know now). They called them "Option Packs" back then which sounds like it just brings another keg to the party not plans to re-arrange the furniture.

Distributing software always sucks, on every OS. It wasn't the language he had a problem with, it was the platform quirks.

"We wanted closure"; left the mess for Lisp. Indeed, the explicit use of closures is closely associated with Lisp.

I am sorry you have been downvotted, but that was indeed a deliberate word-mine, buried for your pleasure.

I do that frequently, but you're the first to point it out :-)

No, wait a sec. A good share of people is complaining about the lack of Microsoft's willingness to push the new shiny stuff - how much time did it take for them to come up with a MVC framework? - the other share of people is complaining that Microsoft pushes too much of a new stuff.

C'mon, people, give me a break - yes, there're lots of new frameworks coming from MS. Well, that's what I would expect the company to do in order to give their developers some other options to be more productive. It's not like MS' competition is sitting around and doing nothing - Google has their own not-invented-here syndrome, Ruby community produces new frameworks every other week, PHP community clones whatever Ruby community produces... Technology isn't frosen and is always a moving target, that's life, get over it.

Apples and oranges:

1) Microsoft is both the tool vendor and the platform vendor. The Ruby community can go ape-shit forking each other on github, but at least the underlying OS remains constant.

2) Microsoft tools cannibalized each other. There is nothing laissez-faire about its offerings: the new kills the old and the entire company, developers, reference materials, publications, marketing, and retail are in lock step. You just couldn't depend on using a disavowed infrastructure without fear of your bookmarks going stale, immediately.

3) They had no reason to phase out products and tools, at least no sensible reason. It's often to harm a competitor. Not only that, but they have sometimes pushed changes for the same of ill-advised aesthetic reasons. You had to be a C++ programmer 1997 - 200 to see how MS can bully. The push to COM and machine generated stub code. The fucked up pre-compilers. The weird new syntax. You could do everything with vanilla C++, but they were trying hard to keep Borland and other compiler vendors at bay, so you had to kowtow and come along with them.

Alright, this is seriously giving me flashbacks and might trigger PTSD.

(1) - I don't see the problem here. Somehow old DOS stuff still works in Windows 7. You need new features? They're coming with the newer OS, but your old features rarely go away. Contrast this with upgrades from PHP 3 to 4 or 5, stillborn Perl 6, great divide between Python 2 and 3.

(2) - Please... Your old frameworks are still there. You are discouraged to use them, but they didn't go away. I seriously don't understand how this is a problem?

(3) - Again, technology is not frosen. Competitors are coming out with new shinier things - why Microsoft should stick to only what was there back 20 years ago? So they push their shiny stuff into the limelight. But given that old frameworks are still in place, it's not a problem.

"The push to COM and machine generated stub code." - I don't understand your grudge here. Why didn't you ask yourself: do _I_ really need to use COM? COM solves some particular problem - was it _your_ problem? Did ole-good Windows API and C++ classes just go away with the advent of COM? I for one am a C++/Win32|64 and .NET dev. Last few years I'm asking myself a question - do _I_ need to use WPF, just because it is there? My answer is no - I'm just ignoring it, as I ignore other shiny things that don't solve _my_ problem.

BTW, maybe this will sound like a blasphemy here, on HN, but Microsoft could teach a thing or two to the "platform vendors" out there. The pace of change and amount of inconsistency that is being introduced by everyone and their dog with web service "APIs" is astounding. Compared to that, MS' approach of keeping of old stuff while introducing new one is simply a god-send.

I worked in a different era than yours. Today, you can pick and choose the microsoft stack you want to use, if any at all, because you have choice and they don't.

Then, you sold software based on polish and integration in UI look and feel. You have to choose your tools very carefully, because of the realities of software publishing and distribution. You don't know how long it takes from the moment you press the CD-ROM, to the moment it goes on the shelf, to when it's bought. If it looks and works OK today, a year from now it would be butt ugly. Only hardware vendors could get away with ugly software. Even anti-virus software is polished and themed to oblivion. But mine corporate software with strong Office integration, it has to look modern, for some modern in the unknown future.

Did ole-good Windows API and C++ classes just go away with the advent of COM?

They didn't. I occasionally write native win32 apps with Dev-C++. But I could not, today, embed all third party components, be they MS' or off-the-shelf, using only pure C++ and win32 API.

There are tiers of Win32 interfaces and libraries, in terms of quality and system integration. On one end you have the Win32 API, and on the other end the latest managed .NET newfangled things (I am ignoring native NT layer and the DDK.) However, in between you have this graveyard of APIs, from OLE to ActiveX to COM to what have you. Each has been pushed with merciless fervor by MS, at a time when they were the only game in town.

I am glad you like your stay on .NET though. Cheers! I myself java just rediscovered Java (the JVM, really) and this is where it's at. Sun couldn't sell for shit, but they knew how to make software.

Wait a minute... You are complaining that you are now forced to have updated looking and function software? Oh. The horror. That's a sure way to make your users mad. Sell them software today that looks like it was written 10 years ago... But wait, it was written 10 years ago.

You are completely pushing the philosophy of technology needs to remain the same and consistant through all of time. Not possible, ever. Technology HAS to evolve or we all sit at a standstill. If you don't want to learn new things and stay modern in technology, then you need to sign up for truck driving, not software development.

They (MS) didn't just sit around trying to find ways to piss you off by coming out with new technology. They released one, found a way to improve, and released that next. Quite blaming the vendors and put the blame squarely where it belongs, with people who refuse to learn and evolve with the technology.

What? Did I not make myself clear or are you incapable of reading?

I am not "complaining about now", I am complaining about 10 years ago. Specifically '98-00. Fireup Wikipedia and do a little MS history research.

I want my software to look fresh and fit in with the UI of the environment. I said was coding for the future, i.e. use the most cutting edge software today, so by the time we put the software on shelves, it doesn't look old.

My #1 issue with MS, really, is that they let the official API stagnate and forced us developers to use Office and IE components, in the hope of integrating them with Windows.

I would make sense of your writing if it wasn't so weirdly phrased.

Did you HAVE to chase every new API as soon as they came out? Did MFC suddenly stop working? Did the Win32 API go away? Why couldn't you just keep going as you were until you really wanted to rewrite to new APIs?

Yes, if you want your corporate productivity app to be Office certified. The UI guidelines are pretty clear about how it should look and behave. First MS pushed the new CommonControls from IE on us, then there was an Office update, then XP came out with new UI elements, like rebars.

With every new release of Windows, Office or IE, the UI got tweaked. Pretty quickly you couldn't even use vanilla C++ anymore to embed the bulk of widgets/controls from Office to do basic stuff like showing spreadsheets in your app. You had to use COM.

I was a sole developer hoping to differentiate myself from other shareware authors by being on MS's good graces. Good grief! I didn't get peace of mind until I dropped them.

And why is that mahmud? Because most developers, by a HUGE margin, wanted to this in VB. And in VB hosting COM controls in your app was super simple.

What I send to see are two classes of MS developers: 1) Those who use the MS stack, but realize they're using tools that they build with and on. 2) Those who use the MS stack, but get stuck thinking that it is the only tool available, period.

The second group of developers sometimes gets an epiphany when they change to a non-MS stack, because its so clearly obvious in the non-MS world that there is no stack that is convincingly better than any other. Group two expresses their outrage at the MS stack. While group one is mystified that they ever thought the MS stack is the end all be all.

Here's a hint as to how to find them ahead of time. Go talk to the guy who does .NET development today and ask what his favorite third-party controls are. If he has none and says, "I only use MS out the box controls" then this person will eventually become part of second group.

That diagnosis about the second group fits me to a T. 100% correct you are, Sir.

I have been a programmer longer, mostly cracking games and writing x86 asm and DOS stuff with Turbo C; but I became a developer on Microsoft's platform and under their auspices.

After Microsoft, I went through a few years of insane productivity and deep, god-level hacking. I have chronicled those stories else on HN. Here is one:

http://news.ycombinator.com/item?id=972423

After I found "success" elsewhere as a programmer. When I finally saw a product of mine being used, shipped, bought, deployed. When I started seeing bug-reports, requests for bulk prices, discounts, and yes, piracy. That's when I made peace with Microsoft and went back to using Windows. I am typing this on XP.

They're an OK company with an OK platform, just not when you're young and impressionable. Beware of the bastards and use portable, 3rd party libraries.

I am done with this thread ..

Perl? You serious? Are you developing text-based system?

My first Perl application, after I put my Win3 app on hold, was a desktop GUI app for printing mailing labels. It had a builtin list building engine that scraped counties throughout Virginia and found information on new home buyers, and applications for building renovation.

It took me 20 days to develop. Perl/Tk.

If memory service me right, and I really could be wrong .. I think I must have been the first one in the world to hack together a bridge between Perl and Office 2000, because I had a developer preview. ActivePerl .. now that was a delightful platform.

Perl empowered me. If it wasn't for Perl, I might have quit software altogether and became a philosophy major, or worse, a mathematician.

The only major failing of Perl is that its error handling facilities just flat out suck. Outside of that, it's a very modern language, albeit a little esoteric at times, and writing maintainable systems with it is possible with some discipline and common sense.

To boot, Perl natively supports modules written in C, and by way of DynaLoader.pm, a programmer can do fun things with exported symbols from object code. I wouldn't go as far as to call DynaLoader.pm a proper FFI, but it definitely gets the job done a lot of the time.

For the same reason selling your body for money might make you feel dirty.

It sounds like he is annoyed at the community that surrounds asp.net MVC development.

There was no mention of money, but not all broke mofos chose to not use asp.net for their web app.

I also believe that asp.net would be completely dead for web development without stackoverflow.com. A shame, because C# with Visual Studio is a very nice environment. Lonely (i.e. no community), but nice.

I thought it wasn't that long time ago MS released Powershell and the latest MSBuild? These are necessities to automate some tasks in software development. Have you seen your build.proj file lately? Is it as nice as ANT or Maven?

Depending on what your practice style is, Java seems to be far ahead in terms of being agile (excuse me for the buzzword). Of course PHP/Python/Ruby are even better.

There's also Rake.net.

I presume GHC is the Glasgow Haskell Compiler and not Guarded Horn Clauses?

Yes.

Speaking of SBCL, I really wish someone would make SBCL stable on Windows. Please. (Windows XP, Vista, and 7. Don't even worry about 64-bit right now, just get 32-bit fully functional and stable.)

OT, but here:

http://clgtk2.wordpress.com/2010/09/16/related-project-sbcl-...

"You could have taken me to a brothel afterwards and wouldn't have felt dirtier."

Thats the quote of the day !

Many feel the same way about the 'my shit doesn't smell' attitude coming from 37Signals, the _creators_ of RoR, not just a random user like in this case.

Reply on news.ycombinator.com