Hacker News Reader

It isn't clear if you meant to imply that Apple has made better decisions with Xcode. If that is what you are saying, I firmly disagree. This isn't meant to imply that MS is better. Having said that, I don't mind complexity in UI for professional tools. I've been programming for longer than a lot of people on this list have been alive (an assumption on my part). You learn the tool you have to use and move on. No big deal.

I have problems with dumb-ass decisions that make your job harder. Like compilers that don't accept /a/path/that has/spaces/in the string/. Or the absolutely dumb-founding way Xcode does not let you organize your files in a real file structure, you know, with directories and stuff, in the file system. Or how hard Xcode makes it to create use and maintain code libraries. I don't need my IDE to look and act like an iTunes clone. Thank you very much. Pretty doesn't matter to me. Easy and incredibly flexible and functional does. I mean, take the way they've absolutely ruined documentation access in Xcode 4 when compared to Xcode 3. True to iTunes style, the Organizer is overloaded with all kinds of crap it probably shouldn't do.

Anyhow, no tool is perfect, but there are salient examples of the less-than-perfect even in 2012.

I have clarified my point in another comment already. It's not about who's better. It's about who's trying to experiment and rethink things. In developer tools team of the top-10 tech company you have a great combo: best hard-core engineers on the planet + little need to maintain cruft and worry about competition. Why not experiment and try to be better at what you do? Xcode 4 is this radical attempt to improve old problems (of course introducing new ones). And VS does not try to eliminate old obvious problems and almost stays where it is in terms of UI.

Update: here are related thoughts on the subject: http://blog.oleganza.com/post/18156593863/why-apple-products...

> Why not experiment and try to be better at what you do?

Herein lies the problem. The term "better" is most definitely subjective.

Not to pic on Xcode, but this is a prime example of focusing too much on making a consumer appliance rather than a professional tool. Like I said: I don't want iTunes, I want a kick-ass IDE.

I'm in the middle of a project that has, quite literally, thousands of assets to manage (images, audio, video). The thousands of files end-up piled-up without any semblance of organization in the project directory. I mean, who woke up one day and though "This is a good idea!" when you have a perfectly good file system to take advantage of? Updating assets is an absolute nightmare.

Yes, yes, there are crafty work-arounds. Each with its own pros-and-cons. The point is that the IDE itself was designed to totally ignore the underlying file system. Let's put it this way: If I wrote code like that at the many jobs I've had over the years I would have gotten fired in a microsecond. Yet, for some reason, this is "feature" is now considered good design?

Back to coding.

The key was "try". Xcode is far from being focused on "consumers" and they are trying hard to make a kick-ass IDE. It could be a different definition of "kick-ass" from yours, that's fine.

Anyway, I emphasize this again: it's not a question if the actual result is better or worse, it's a complex question because there are thousands of people to evaluate it. The question is why not to experiment more where you have more liberty to do so. It's hard to experiment with a toolbar in Excel because millions of non-computer-geek users are used to certain operations and want to preserve their productivity. But it's not hard to throw away toolbar in an IDE because nobody will pay you less because of it. (Especially if you are actually trying to do your best.)

Metro after Windows is that kind of experiment (but way more risky and rewarding, of course). But Visual Studio is not inspiring at all after all these years.

PS. For that matter, Xcode 4 is not radical enough too. We are still typing a lot of boring cruft (even with ever-smarter autocompletion). But it's a huge difference with Xcode 3 and other IDEs out there.

>It's hard to experiment with a toolbar in Excel because millions of non-computer-geek users

Excel is another of my favorite "Why did they do that?" examples. In my opinion, MS absolutely ruined Excel somewhere in the transition from Office 2003 to 2007. If you were a power user with Excel'03 you felt like a total idiot with Excel'07. And, this wasn't a matter of a few buttons here and there. The thing was almost utterly unusable compared to what you could do with the '03 version. Furthermore, they complicated the usage of VBA modules. If you had a library of VBA work that you used regularly you, all of a sudden, found yourself scratching your head trying to figure out how to do some pretty basic stuff.

I use Excel extensively for automated code generation. Simple examples are the generation of repetitive lookup table code in various languages. Or code to pre-stuff database tables. Or maintaining a complex LUT-driven state machine. I have custom Excel tools that have taken months to develop that do increase productivity in a measurable way. For example, one tool uses Excel to auto-magically write the code (LUT, callbacks, etc.) for a menu system on an embedded device with an LCD display. Before the tool it'd take hours, if not a couple of days, to maintain. After the custom VBA tool it was a matter of minutes.

Anyhow, upon switching to '07 (mostly a forced switch because I needed to migrate to a 64 bit OS for Finite Element Analysis work) I went from light speed to crawling. That, to me, is not an improvement. I am OK with learning new things, you have to be open to it if you want to remain in this game, but sometimes you can't help but scratch your head and try to figure out what the hell they were thinking.

Thankfully that was easily solved with a VM running XP and Excel'03.

I use Excel extensively for automated code generation.

I'm not going to argue if this is a good thing or a bad thing to do, but even you have to agree that this is an extremely rare thing to do, and something that would be more or less impossible for Microsoft to anticipate you doing.

Of course. This was just one illustration of Excel as an augmentation tool. There are probably thousands of such special applications out there, some commercial, some not, that used Excel this way.

The greater point, perhaps, is that making things prettier at the expense of raw functionality isn't always the best idea.

For the record, on first inspection I like the outer appearance of VS 2011. I like the pictographic icons and clean uncluttered appearance. I hope that this effort did not come at the expense of function elsewhere. We'll upgrade when it comes out of beta and see.

I will argue, as I don't know who the submitter is, or even what this site is. HackerNews I think? I just got here via a Twitter post. So I have nothing to lose.

If you're using Excel for automated code generation, YOU'RE DOING IT WRONG

Surely there are better tools out there for the task.

Using tools in wrong way is a kind of entertainment for hacker. But hacker shouldn't complain if something breaks.

That's really funny partner. Using Excel for generating code fragments that can be cut and pasted into your compiler is powerful and fast. Nothing wrong with it. But, go ahead and don't. I love compete with others doing thing less efficiently. Makes me smile.

May I humbly suggest that you are mixing your data up with your code? Could you not just put the data in an external Excel file (or *.txt file, whatever) and read that in when you run your code?

This has a number of advantages:

- you don't need to change your code every time the data changes.

- you can version the data and the code seperately within your source control management system.

- you don't need to write any VBA. (always a winner, that one)

- current developers will be able to understand and change the code without being forced to use the macro you developed, or have it explained to them.

- future developers will be able to understand where all the code came from, and be able to effectively understand and change it.

- you will be less affected by changes to future versions of Excel.

He mentioned generating code for an embedded system. In that particular situation what you suggest may not be possible.

On the other hand what would be possible (and I've done this a few times before) is write a program or script (I like writing it in Python) that takes the .xls/.csv/.txt/.json file (which is pure data, can be edited in many programs etc) and generates the C/C++/whatever code from that. Basically the best of both worlds.

Dunno about 03 but I recently installed Office XP (2002) almost without pb on a Windows 7 64bits. The only pb was with the companion help API that doesn't exist anymore on Vista/7 but is downloadable as a hotfix from Microsoft.

So I'm perplex about the need of a VM to run Excel 03 and won't debate about the use of it to generate code as anyone have different habits for his workflow.

"pb" means "problem"?

I couldn't agree more. '07 excel is a major change from '03. I know that they are trying more of a shotgun approach to reach deeper into business but I'm not sure if MS considered how they have alienated the power users. '10 is much more SharePoint focused which I love but SharePoint out of the box is very very limited.

>PS. For that matter, Xcode 4 is not radical enough too. We are still typing a lot of boring cruft ... But it's a huge difference with Xcode 3 and other IDEs out there.

I can only conclude that you have absolutely no concrete experience of the state of other tools and languages. Eclipse, IntelliJ and Visual Studio with Resharper are lightyears ahead of XCode 4 when it comes to assisted programming.

Here's the clue: all of these tools expose the code DOM to tool writers. Even if Intellij didn't have over 100 different ways to refactor code, I could write my own. Fuck, I wrote a Resharper plugin that loaded javascript file to manipulate the dom and pass it to StringTemplate [1] The javascript file then decides based on what is at the cursor which templates to display when the user hits Alt-Enter. Think for a minute about what has to happen under the hood for that to happen. Then think what else is possible. Then realize that its not there in XCode 4.

[1] http://www.stringtemplate.org/

> We are still typing a lot of boring cruft

This is more due to a language/API design flaw, actually. When a program (a preprocessor, a part of the IDE) generates more code starting from the code you actually wrote, it's because, for some reason, whatever you expressed in your code could not express enough to build the whole application.

XCode 4 may have been designed but it wasn't designed well. It has no mixed source/disassembly views. Hovering over the debug icons say that pressing control and clicking "step into" will step a single instruction. But this isn't a sticky setting, so if I press control and click "step into" twice, the first time will step an instruction and the second will perform a source line step.

It also crashes. A lot.

When doing iOS development I find myself switching between GDB and LLDB regularly, as LLDB gives some great context information but it crashes and takes out all of Xcode on a fairly regular basis.

Xcode is terrible. It's really quite sad that a company that prides itself as much as Apple does on its user experience is able to let something so unusable out its doors. Xcode 3 may have been messy but it was many times more usable because it was many times more stable than Xcode 4. I don't really care how pretty my tool interfaces are but rather how well they work.

Try Jetbrains AppCode. It's the best $99 any serious Mac or iOS developer can spend.

The stability will get there eventually.

Xcode 3 got a lot better over the years.

But it isn't encouraging that they'd push the release out with what seems to be blatant crashes. It sort of feels like the developers are left out to dry and they have to soldier on. Personally, I rely on git to make sure I don't screw up my project/code to the point where the IDE crashes repeatably. And that's unacceptable.

It's called integrity. And although XCode has it from a design sense, it doesn't appear to have it in the engineering department.

Most programmers fall into one of two categories: console editor (e.g. vim) or IDE. The IDE camp includes Visual Studio, Eclipse, IntelliJ, SlickEdit, NetBeans, MonoDevelop, etc.

These IDEs have an almost identical design language. I am at home in any of them and picking up new ones is pretty straightforward.

XCode 4 on the other hand has a completely different design language, and one that is limited in what it can do, but verbose in achieving it.

Limited, for example, because while I have a 17" MBP and a 23" monitor, I can't have the Project Navigator open at the same time as the Error Navigator. I can't view code and disassembly. I can't have code side-by-side in a split view.

Verbose, for example, because when editing a Scheme, it opens a custom, modal dialog, and if I press "Manage Schemes..." it rolls up and then rolls down another custom, modal dialog. If I then hit "+" it opens another modal dialog on top of my modal dialog. I thought we got rid of this kind of shit with VB6.

I've built a complicated IDE or two, and every time there was a custom, modal dialog, it was because we were rushed for time. Good non-modal design requires thought and effort. Flexible UI requires thought and effort. A simple, powerful design language requires thought and effort.

I would put money on XCode 4 not so much being "designed" as "rushed". Or perhaps "designed with lofty goals" - and one of those being "not like any other IDE, so that programmers learning on XCode will be completely thrown by any other tool".

Many changes in Xcode 4 seem to have been made entirely for cosmetic reasons. The default error list pane on the left hand side, for instance, cuts off 80% of the error message text. Jetbrains' AppCode UI may not look as much like an iTunes clone but it seems to have been designed with developer productivity as top priority.

Example of throwing away old cruft: Xcode 4 did not (and I guess still does not) support Interface Builder plugins. Meaning, you have to add third-party UI components in code rather than with mouse in a visual editor. But integrating IB into the rest of workflow was decided to be more important.

Now, I'm not arguing it was right decision. My point is that both Apple and MS can afford making such decisions without effect on profits. If JetBrains throws away a feature, their sales drop. How much less Macs, Xboxes or Windows copies would have been sold if some convenience features were removed from or drastically changed in a developer tool?

I personally think that Microsoft should stick with things that only Microsoft can do, and leave the more cutting-edge innovations to others.

Example: the test automation tools into Visual Studio were terrible. Maybe they still are, I don't know, I've stopped using them. nUnit is just better. Their automated refactoring stuff may be OK, but the stuff from JetBrains is much, much better. Don't get me started on Team Frustration Server.

If they want to simplify and clean up their UI by starting with lower contrast icons to make the IDE background and the code foreground, that's totally a step in the right direction.

> the test automation tools into Visual Studio were terrible

It went from "just plain bad" in VS2008 to "horribly awful" in VS2010. So awful that someone at MS named the process that manages the unit testing "QTAgent", so that when your machine slowed to a crawl and you opened the Task Manager to see what was wrong you'd see "QT" and conclude it was a background update issue with Apple QuickTime.

> I personally think that Microsoft should stick with things that only Microsoft can do

I'm very curious to see that list...

Microsoft (either explicitly or de-facto) owns the Common Language Runtime, the C# language, Entity Framework, ASP.NET, IIS, Windows OS, Windows Phone OS, XBOX, XBOX live, etc.

An example that I think of is LINQ (not linq-to-sql, mind you, but the language-integrated query stuff). So many things were required to make LINQ viable in the language and the tools, etc. that it doesn't seem realistic to expect an external dev team to throw something like that together. That stands in contrast to things like test automation, which nUnit had already been doing very well for years before Visual Studio tried to get into it.

I'm really not sure any of those is something only Microsoft could do, much less in the restricted scope of development tools.

When you say "that it doesn't seem realistic to expect an external dev team to throw something like that together", you are giving Microsoft's internal teams a power they simply don't have outside their very narrow zone of influence, as there is a lot of stuff being done outside it.

It seems smart to just clean up rather than alienate their users with radical and risky changes. People just want to code... Not learn a new interface to code...