5 ms·

As a knowledgeable Microsoft basher, you're right. MVC is better but still a long step away from something great. Some of the internals are crazy bad from attri

by d0 13y ago

As a knowledgeable Microsoft basher, you're right. MVC is better but still a long step away from something great. Some of the internals are crazy bad from attribute thread safety to the numerous singleton piles of crud like the ViewEngines collection and route data. Not only that, the tooling really doesn't scale up well either. I can only say after managing a project with 400 controllers that it doesn't scale up to complex UI or even medium sized projects well. Also we're reaching 5 minute edit, compile, run cycles (on E5 Xeons!). Also production debugging (which is inevitable one day) is a PITA on CLR based projects. It has become the opposite of all promises. It's like wading through tar. To be honest after over a decade of .Net experience and over a decade of Win32/COM etc before that, I'm tired of it all. I wrote my first Objective C+Cocoa application last week (an RPN calculator) and it's where I'd rather be. It was fun and frustration free. I tried to do exactly the same with WPF/C# a few weeks ago and it was horrible.

thomasz 13y ago
I feel exactly the same way, but we should be aware that the grass is always greener on the other side.
- d0 13y ago
  I'd say the grass was less yellow :)
UK-AL 13y ago
WTF? You complain about singletons, then prefer a language where the use of [sharedInstance] is extremely common. Objective-C is singleton hell. Both in third party code, and core libaries. C# is vastly nicer than objective-c, and I'm a iOS developer. I'd rather use C# or Scala with a IoC container to handle the lifetime of objects, rather than using singletons.
- d0 13y ago
  Yes exactly that. The difference is that your Objective-C/iOS application doesn't consist of thousands of threads which require synchronised access to these objects. It's a pretty static thing with an event loop. Possible a couple of background worker threads. For a desktop application or even mobile application it's fine but for a massively scalable back-end enterprise system it's a pain in the butt. Singletons are not for managing lifetime as well. They are a container for an object -- nothing else. Lifetime should be managed separately i.e using a container/service locator or something. Everything I've seen Cocoa-wise is pretty decoupled so far. There are some crimes but only inexperience seems to require them.
  - UK-AL 13y ago
    "Singletons are not for managing lifetime as well" - No, but you can replace it with something that does. I.E Single Object with application lifetime vs singleton.
    - d0 13y ago
      Or a singleton that exposes a service locator (which is the pattern I've been using in Cocoa).
josteink 13y ago
So you had an extremely large .NET project and complained it didn't scale. And since you attribute those problems to .NET, your solution is a small project (which incidentally uses another technology). Not dismissing your argument as a whole, but you have to admit you made at least one giant logical fallacy right there.
- d0 13y ago
  You're right. 100% right -- I agree with you. Let me break it down into to separate points which are better described. The problems with the project scaling are primarily down to the infrastructure: MSBuild and the C# compiler are damn slow as is the whole rip up and replace assembly system in .Net. When you have something at the bottom of a dependency chain that is quite deep (with any enterprisey project), you have to recompile all consumers and therefore everything that depends on them and so forth. A single line change means you end up compiling the entire system on top of it. All 200Mb of DLLs need building again. That's a long time. Not only that, when it comes to testing and runtime dev (i.e. using the web front end), reloading assemblies and performing JIT is really expensive and time consuming. Every time you do something, mount everest is destroyed and recompiled twice: one to IL and once to native. This is expensive and seriously screws productivity. It doesn't scale development-wise. Simple as. This is not specific to my current project - I've consulted at various companies since 2002 and that's exactly what it has ended up for everyone, every time. Going back to LLVM/XCode. I'm not particularly experienced with the specifics of the abstraction that Apple provide, but I've spent 20 years building monstrous bits of C on top of Unix/Linux with GCC and Sun compiler suite. That's what we're still dealing with but we have LLVM which slings code out much faster than anything we've had before. We also have incremental build support (individual .o files per source file), faster linking and a runtime system that doesn't require recompilation. I'm not saying it'll realistically turn into anything better at the end of the day but one some points: 1. The Xcode tooling is like lightning, even with a 200,000 line C project I imported from a previous project. 2. The startup time is 487ms compared to the same thing in C# of 2.2s to first output and 10.5s to it actually doing something. Think I've explained myself better now. Sorry for the initial confusion.
  - 13y ago

by d0 13y ago

thomasz 13y ago

I feel exactly the same way, but we should be aware that the grass is always greener on the other side.

d0 13y ago
I'd say the grass was less yellow :)

UK-AL 13y ago

WTF? You complain about singletons, then prefer a language where the use of [sharedInstance] is extremely common. Objective-C is singleton hell. Both in third party code, and core libaries. C# is vastly nicer than objective-c, and I'm a iOS developer. I'd rather use C# or Scala with a IoC container to handle the lifetime of objects, rather than using singletons.

d0 13y ago
Yes exactly that. The difference is that your Objective-C/iOS application doesn't consist of thousands of threads which require synchronised access to these objects. It's a pretty static thing with an event loop. Possible a couple of background worker threads. For a desktop application or even mobile application it's fine but for a massively scalable back-end enterprise system it's a pain in the butt. Singletons are not for managing lifetime as well. They are a container for an object -- nothing else. Lifetime should be managed separately i.e using a container/service locator or something. Everything I've seen Cocoa-wise is pretty decoupled so far. There are some crimes but only inexperience seems to require them.
- UK-AL 13y ago
  "Singletons are not for managing lifetime as well" - No, but you can replace it with something that does. I.E Single Object with application lifetime vs singleton.
  - d0 13y ago
    Or a singleton that exposes a service locator (which is the pattern I've been using in Cocoa).

josteink 13y ago

So you had an extremely large .NET project and complained it didn't scale. And since you attribute those problems to .NET, your solution is a small project (which incidentally uses another technology). Not dismissing your argument as a whole, but you have to admit you made at least one giant logical fallacy right there.

d0 13y ago
You're right. 100% right -- I agree with you. Let me break it down into to separate points which are better described. The problems with the project scaling are primarily down to the infrastructure: MSBuild and the C# compiler are damn slow as is the whole rip up and replace assembly system in .Net. When you have something at the bottom of a dependency chain that is quite deep (with any enterprisey project), you have to recompile all consumers and therefore everything that depends on them and so forth. A single line change means you end up compiling the entire system on top of it. All 200Mb of DLLs need building again. That's a long time. Not only that, when it comes to testing and runtime dev (i.e. using the web front end), reloading assemblies and performing JIT is really expensive and time consuming. Every time you do something, mount everest is destroyed and recompiled twice: one to IL and once to native. This is expensive and seriously screws productivity. It doesn't scale development-wise. Simple as. This is not specific to my current project - I've consulted at various companies since 2002 and that's exactly what it has ended up for everyone, every time. Going back to LLVM/XCode. I'm not particularly experienced with the specifics of the abstraction that Apple provide, but I've spent 20 years building monstrous bits of C on top of Unix/Linux with GCC and Sun compiler suite. That's what we're still dealing with but we have LLVM which slings code out much faster than anything we've had before. We also have incremental build support (individual .o files per source file), faster linking and a runtime system that doesn't require recompilation. I'm not saying it'll realistically turn into anything better at the end of the day but one some points: 1. The Xcode tooling is like lightning, even with a 200,000 line C project I imported from a previous project. 2. The startup time is 487ms compared to the same thing in C# of 2.2s to first output and 10.5s to it actually doing something. Think I've explained myself better now. Sorry for the initial confusion.
- 13y ago