It looks like Microsoft is losing mindshare in people coming out of college. I cannot say that this is surprising, although the connection that is made between that and the KIN phone is something I find surprising, as I had no idea that it even existed before it was cancelled.

If Microsoft is losing mindshare in this area, then what languages are the people coming out of college using? At my university, all of the computer science majors graduate with a certain level of proficiency in Java, because it is required in almost all programming courses in the curriculum, with the exception of games programming. If young developers are not using Microsoft software, then I know for certain that they are not using .NET. In which case, are these developers doing programming in C/C++, Java or some other language, like Python or Objective C?

computer science (ie... school of engineering) students have access to msdnaa but are not automatically enrolled. they have to seek it through the university student liason if they want access to ms tools (most do it just to get the os and other niceties).  computer science students intro classes were taught with python, then different track options for java and c++, depending on the student's choice. of course nothing stops a cs/engineering student from taking an mis/cis course, but since it wasn't a requirement of the degree, it rarely happened and vice/versa (mis/cis students rarely took cs classes).

 I've been doing C# after getting into XNA. I wanted to learn some new tech in the summer and decided on C# because MS gives me a free copy of VS2010 and C# is an accessible and productive language. Being hooked ever since. But most students don't care for MS technologies since the school stays clear of it. I think the Dreamspark and MSDNAA initiatives are a good start, XNA is also a nice push. MS needs to show how easy it is to build complex apps with their tools to win over more students. 

There has always been a conflict between what's taught on a CS Course and what business wants out of developers.

15 years ago there were articles complaining that CS graduates were terrible developers; they got CS Degrees that taught them how to design a CPU, or mathematically prove an algorithm was correct, but that didn't teach them how to follow a spec from a client.

Now CS degrees have moved the skillsets they teach closer to what business wants, and it's just the toolset that differs. Business isn't going to suddenly change its ways to suit the CS courses taught.

Herbie

Bas said:

Hey guys I haven't seen a lot of scare-stories about dwindling interest for Microsoft technologies lately, can anyone recommend some?

If you don't love open-source software when you're young, you have no heart.

If you don't love some Microsoft software when you're older, you have no brains.

Keep on loving!   (sorry)

brian.shapiro said:

What makes them hip?

Not using fuddy duddy MS platforms.

Oh. Hey. Wait a minute ....

I'm not sure what a "young, hip developer" is. I think "hip developer" is an oxymoron within its own right.

It is worrying how unpopular ASM, C/C++, and other lower level languages are outside of the elite technology schools - some of which barely give a good programming education as is.

edit: Seems the NY piece is a bunch of lies that misquoted Tim O' Reilly. What he actually said was that young startup companies are very interested in mobile platforms - iOS 4.0 and Android. Which sounds like it could be true, mobile platforms are cheap relatively speaking to create revenue generating software for. I would say that Microsoft might be falling behind in that area as they lack any real competition in the mobile area (despite what you read on the C9 forums)/

ManipUni said:

I cannot speak to this article but I know a lot of college graduates and people in masters programs, I would say C#, VB.Net, and Java are all very popular. The reason why is very simple - all three are free to learn and have great resources for students. Universities seem to be adopting C# from Java however.

 

I'm not sure what a "young, hip developer" is. I think "hip developer" is an oxymoron within its own right.

 

It is worrying how unpopular ASM, C/C++, and other lower level languages are outside of the elite technology schools - some of which barely give a good programming education as is.

 

edit: Seems the NY piece is a bunch of lies that misquoted Tim O' Reilly. What he actually said was that young startup companies are very interested in mobile platforms - iOS 4.0 and Android. Which sounds like it could be true, mobile platforms are cheap relatively speaking to create revenue generating software for. I would say that Microsoft might be falling behind in that area as they lack any real competition in the mobile area (despite what you read on the C9 forums)/

for us it was different .... all design students - in all colleges - are taught on MACs - illustrator.

we were a web shop - and pc design ad shop.  the photoshop work learned was good - but illustrator in our world is like a word perfect file in a word shop = akkk!

the only thing i hate more than ballmer is illustrator    bloated eps - die! die! die!

* i agree with jobs again = adobe SUCKS  (eps = die   PFB = die  FLV = die etc)

I agree it's because Univerisites perfer open source. CS depts (or at least good ones) are all about scientific collaboration and openness. Microsoft's vast assortment of binary blobs really doesn't fit into that.

http://www.google.com/buzz/timoreilly/j61qZ42h6rB/Frustrated-by-flamebait-NY-reporting-in-Microsoft

Congrats for falling for this so easily, Shining Arcanine.

Dr Herbie said:

Meh.

 

There has always been a conflict between what's taught on a CS Course and what business wants out of developers.

15 years ago there were articles complaining that CS graduates were terrible developers; they got CS Degrees that taught them how to design a CPU, or mathematically prove an algorithm was correct, but that didn't teach them how to follow a spec from a client.

 

Now CS degrees have moved the skillsets they teach closer to what business wants, and it's just the toolset that differs. Business isn't going to suddenly change its ways to suit the CS courses taught.

 

Herbie

 

Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

That might be the result of really good pre-screening on the part of HR though.

What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

void MyFunction(string input)
{
    string dest;
    int dotIndex;
    while ((dotIndex = input.find(".")) != string::npos)
    {
        dest.push_back(input.substr(0, dotIndex-1);
        dest.push_back("\.");
        input.erase(0, dotIndex);
    }
}

instead of:

void MyFunction(string input)
{
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
        if (*inputString == '.')
        {
            dest.push_back('\');
        }
        dest.push_back(*inputString);
        inputString += 1;
    }
}

Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

Larry Osterman said:

Dr Herbie said:

*snip*

Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

 

That might be the result of really good pre-screening on the part of HR though.

 

What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

void MyFunction(string input)
{
    string dest;
    int dotIndex;
    while ((dotIndex = input.find(".")) != string::npos)
    {
        dest.push_back(input.substr(0, dotIndex-1);
        dest.push_back("\.");
        input.erase(0, dotIndex);
    }
}

instead of:

void MyFunction(string input)
{
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
        if (*inputString == '.')
        {
            dest.push_back('\');
        }
        dest.push_back(*inputString);
        inputString += 1;
    }
}

Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

 

I would've just written:

void MyFunction(const string &input)
{
}

Since both functions you wrote actually don't have any externally visible effects. Also you need to escape the backslash.

Seriously though, I can understand how someone might want to use find for this problem, but erase? Surely most people that know about find should know it accepts a second parameter to tell you where to start searching?

Also if this is really performance critical I wouldn't let dest auto-resize like that, I'd call string.reserve with at least the size of the input string. And I'd make input a const reference parameter.

And lastly, I'd use wstring. Death to ANSI code pages!

Larry Osterman said:

Dr Herbie said:

*snip*

Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

 

That might be the result of really good pre-screening on the part of HR though.

 

What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

void MyFunction(string input)
{
    string dest;
    int dotIndex;
    while ((dotIndex = input.find(".")) != string::npos)
    {
        dest.push_back(input.substr(0, dotIndex-1);
        dest.push_back("\.");
        input.erase(0, dotIndex);
    }
}

instead of:

void MyFunction(string input)
{
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
        if (*inputString == '.')
        {
            dest.push_back('\');
        }
        dest.push_back(*inputString);
        inputString += 1;
    }
}

Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

 

OK, how do we know you are real?  Show us a bit of that pre-emptive multitasking code then maybe we'll see ..

rd3d2 (Bill G)

Larry Osterman said:

Dr Herbie said:

*snip*

Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

 

That might be the result of really good pre-screening on the part of HR though.

 

What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

void MyFunction(string input)
{
    string dest;
    int dotIndex;
    while ((dotIndex = input.find(".")) != string::npos)
    {
        dest.push_back(input.substr(0, dotIndex-1);
        dest.push_back("\.");
        input.erase(0, dotIndex);
    }
}

instead of:

void MyFunction(string input)
{
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
        if (*inputString == '.')
        {
            dest.push_back('\');
        }
        dest.push_back(*inputString);
        inputString += 1;
    }
}

Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

 

Possibly a cultural thing -- perhaps UK Universities were too academic while US Universities were a bit more practical.  I read a whole spate of magazine articles while I was doing my PhD including one by a (I think) a leading member of the CBI who categorically stated that he avoided employing CS graduates as programmers. Unfortunately this was a good, old-fashioned hardcopy magazine made of dead trees, so I can't provide a link (or find out exactly who the article was by)

Herbie

EDIT: self-doubt creeping in -- may not have been the CBI, but some other organisation.  Stupid interwebs; why can't you reference magazines from the 1990's?

ManipUni said:

I cannot speak to this article but I know a lot of college graduates and people in masters programs, I would say C#, VB.Net, and Java are all very popular. The reason why is very simple - all three are free to learn and have great resources for students. Universities seem to be adopting C# from Java however.

 

I'm not sure what a "young, hip developer" is. I think "hip developer" is an oxymoron within its own right.

 

It is worrying how unpopular ASM, C/C++, and other lower level languages are outside of the elite technology schools - some of which barely give a good programming education as is.

 

edit: Seems the NY piece is a bunch of lies that misquoted Tim O' Reilly. What he actually said was that young startup companies are very interested in mobile platforms - iOS 4.0 and Android. Which sounds like it could be true, mobile platforms are cheap relatively speaking to create revenue generating software for. I would say that Microsoft might be falling behind in that area as they lack any real competition in the mobile area (despite what you read on the C9 forums)/

"'hip developer' is an oxymoron"

Ian2 said:

Larry Osterman said:

*snip*

OK, how do we know you are real?  Show us a bit of that pre-emptive multitasking code then maybe we'll see ..

 

rd3d2 (Bill G)

Ian2: What do you mean "real"?  If you're asking if I'm the same person who writes http://blogs.msdn.com/larryosterman, the MSFT watermark on my posts should be enough .

Others: And you're right that the function has no side effects - it's an interview question. And in an interview, I don't care about string vs wstring - they don't matter.   And even if they'd removed the .erase, the function is STILL broken - the core mistake was using string::find() - that causes the function to run in O(n^2) instead of O(n).

But the developer in question didn't know that and didn't understand why a O(n) algorithm is better than an O(n^2) algorithm.

And that's totally unacceptable to me.

Ian2 said:

Larry Osterman said:

*snip*

OK, how do we know you are real?  Show us a bit of that pre-emptive multitasking code then maybe we'll see ..

 

rd3d2 (Bill G)

@Ian:  YOW!!  Hey Larry is the real deal.... he's been a round MS for a *LONG* time :--)

Larry Osterman said:

Ian2 said:

*snip*

Ian2: What do you mean "real"?  If you're asking if I'm the same person who writes http://blogs.msdn.com/larryosterman, the MSFT watermark on my posts should be enough .

 

Others: And you're right that the function has no side effects - it's an interview question. And in an interview, I don't care about string vs wstring - they don't matter.   And even if they'd removed the .erase, the function is STILL broken - the core mistake was using string::find() - that causes the function to run in O(n^2) instead of O(n).

 

But the developer in question didn't know that and didn't understand why a O(n) algorithm is better than an O(n^2) algorithm.

 

And that's totally unacceptable to me.

I wasn't being entirely serious with all my responses.

Though I have to ask, unless I'm missing something (and it's entirely possible since it's past midnight and I got up early today), I don't see why using string::find makes it O(n^2). Ignore erase for a moment, let's say it was done the more logical way by just keeping track of the last index and passing that as an offset to find. That means the contents of input are scanned twice, once to find the periods, once to copy it. That's O(2n) which equals O(n), not O(n^2), isn't it?

Again, I could easily be wrong. Please enlighten me.

figuerres said:

Ian2 said:

*snip*

@Ian:  YOW!!  Hey Larry is the real deal.... he's been a round MS for a *LONG* time :--)

Yeh, I posted that and then had one of those 'why did I just post that' moments.  Having said that its probably part of what defines me as a geek (with just a little nerd thrown in for good measure).

My 'favourite" interview question was something about if I was coding in the sixties what would I be doing differently?  I think I fuddled it and said something about having to be way more careful about performance (it still matters, but in those days just wasn't optional).  I got the job so I guess that was an OK answer.  I don't like code specific questions because I don't keep syntax stuff in my head (at least since intellisense was invented)

Sven Groot said:

Larry Osterman said:

*snip*

I wasn't being entirely serious with all my responses.

 

Though I have to ask, unless I'm missing something (and it's entirely possible since it's past midnight and I got up early today), I don't see why using string::find makes it O(n^2). Ignore erase for a moment, let's say it was done the more logical way by just keeping track of the last index and passing that as an offset to find. That means the contents of input are scanned twice, once to find the periods, once to copy it. That's O(2n) which equals O(n), not O(n^2), isn't it?

 

Again, I could easily be wrong. Please enlighten me.

Actually, I hadn't considered the use of substr which creates an additional temporary. Not entirely sure if that makes it O(n^2) though (as an aside, string::push_back only accepts a char so the original sample doesn't compile anyway, that's beside the point though).

But my assertion was that using string::find doesn't automatically mean it becomes O(n^2). If we rewrite the bad algorithm thusly, so it no longer uses substr or erase:

string MyFunction(const string &input)
{
  string dest;
  int prevIndex = 0;
  int index;
  while( (index = input.find('.', prevIndex)) != string::npos )
  {
    dest.append(input.begin() + prevIndex, input.begin() + index);
    dest.append("\\.");
    prevIndex = index + 1;
  }
  dest.append(input.begin() + prevIndex, input.end());

  return dest;
}

Yes, this is obviously less efficient than Larry's second version. But, I do think it still executes in linear time.

Ian2 said:

figuerres said:

*snip*

Yeh, I posted that and then had one of those 'why did I just post that' moments.  Having said that its probably part of what defines me as a geek (with just a little nerd thrown in for good measure).

 

My 'favourite" interview question was something about if I was coding in the sixties what would I be doing differently?  I think I fuddled it and said something about having to be way more careful about performance (it still matters, but in those days just wasn't optional).  I got the job so I guess that was an OK answer.  I don't like code specific questions because I don't keep syntax stuff in my head (at least since intellisense was invented)

 

Yeah.... i was just kind of surprised when i saw it ...

but then i kind of feel like there are bunch of folks i "know" at MS even if i have never seen them in person.... just been using MS tools for so long and having almost as much time in this stuff as they do...

my war stories go back to DOS after all... and even CP/M

Lol

figuerres said:

Ian2 said:

*snip*

Yeah.... i was just kind of surprised when i saw it ...

but then i kind of feel like there are bunch of folks i "know" at MS even if i have never seen them in person.... just been using MS tools for so long and having almost as much time in this stuff as they do...

 

my war stories go back to DOS after all... and even CP/M

Lol

I'm sure that the combination of all of the videos and their posting in the forums gives us all a stalker type sense that we know people. Not that it's necessarily a bad thing. I promise that if I ever visit the campus that I won't be creepy.

Larry Osterman said:

Dr Herbie said:

*snip*

Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

 

That might be the result of really good pre-screening on the part of HR though.

 

What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

void MyFunction(string input)
{
    string dest;
    int dotIndex;
    while ((dotIndex = input.find(".")) != string::npos)
    {
        dest.push_back(input.substr(0, dotIndex-1);
        dest.push_back("\.");
        input.erase(0, dotIndex);
    }
}

instead of:

void MyFunction(string input)
{
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
        if (*inputString == '.')
        {
            dest.push_back('\');
        }
        dest.push_back(*inputString);
        inputString += 1;
    }
}

Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

 

I would write:

Sub MyFunction(input as String)

   Dim dest as String = input.Replace(".", "\.")

End Sub

Let the framework designers worry about algorithm performance. I just want the result.

spivonious said:

Larry Osterman said:

*snip*

I would write:

 

Sub MyFunction(input as String)

   Dim dest as String = input.Replace(".", "\.")

End Sub

 

Let the framework designers worry about algorithm performance. I just want the result.

That was my thought too -- which is why I'll probably never be good enough to work for Microsoft

Herbie

Sven Groot said:

Sven Groot said:

*snip*

Actually, I hadn't considered the use of substr which creates an additional temporary. Not entirely sure if that makes it O(n^2) though (as an aside, string::push_back only accepts a char so the original sample doesn't compile anyway, that's beside the point though).

 

But my assertion was that using string::find doesn't automatically mean it becomes O(n^2). If we rewrite the bad algorithm thusly, so it no longer uses substr or erase:

string MyFunction(const string &input)
{
  string dest;
  int prevIndex = 0;
  int index;
  while( (index = input.find('.', prevIndex)) != string::npos )
  {
    dest.append(input.begin() + prevIndex, input.begin() + index);
    dest.append("\\.");
    prevIndex = index + 1;
  }
  dest.append(input.begin() + prevIndex, input.end());

  return dest;
}

 

Yes, this is obviously less efficient than Larry's second version. But, I do think it still executes in linear time.

FUD

C

Dr Herbie said:

Meh.

 

There has always been a conflict between what's taught on a CS Course and what business wants out of developers.

15 years ago there were articles complaining that CS graduates were terrible developers; they got CS Degrees that taught them how to design a CPU, or mathematically prove an algorithm was correct, but that didn't teach them how to follow a spec from a client.

 

Now CS degrees have moved the skillsets they teach closer to what business wants, and it's just the toolset that differs. Business isn't going to suddenly change its ways to suit the CS courses taught.

 

Herbie

 

I do not think business interests should have any say in the design of college curricula. They exist to educate people, not to train them like pigeons. Let businesses train their own employees.

By the way, for anyone who does not understand the pigeon reference:

http://www.time.com/time/magazine/article/0,9171,909994-5,00.html

http://www.google.com/technology/pigeonrank.html

The google link is actually a joke, but the link to Time.com shows that it is rooted in reality. With proper training, pigeons can be made to do a great number of things.

Larry Osterman said:

Dr Herbie said:

*snip*

Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

 

That might be the result of really good pre-screening on the part of HR though.

 

What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

void MyFunction(string input)
{
    string dest;
    int dotIndex;
    while ((dotIndex = input.find(".")) != string::npos)
    {
        dest.push_back(input.substr(0, dotIndex-1);
        dest.push_back("\.");
        input.erase(0, dotIndex);
    }
}

instead of:

void MyFunction(string input)
{
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
        if (*inputString == '.')
        {
            dest.push_back('\');
        }
        dest.push_back(*inputString);
        inputString += 1;
    }
}

Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

 

Did you ask him what the computational complexity of his algorithm was? It looks O(nm) to me, while yours is O(n). When the entire string consists of '.', you can call it O(n^2).

By the way, dotIndex will give you a compiler warning in the second one, because it is not used.

Charles said:

In some sense, we could do a better job of focusing our platform wares (how many tools does it take to do the same thing?) and highlighting the great things that are built using them. Make no mistake, Windows is a great platform to target should you want to get into the software business. Windows is a big tent and any number of applications, using any number of tools, can be written to get the most out of Windows. The question is: why has Windows client app development declined? The tooling? Maybe. What do you think?

 

C

The web is a royalty free standard with many different vendors (Apple, Mozilla, Microsoft, etc.) involved so it doesn't have the same lockin potential. The standards based web is open and a relatively slow moving target with extreme backwards compatibility.

Lockin is a disaster, it leads to software rot. Software really doesn't rot, just like the Pythagorean theorem doesn't rot. But yet many enterprises are spending millions of dollars rewriting "legacy" code that is only legacy because it was locked into some vendor's platform or product line that is either retired or doesn't exist anymore. The ideal stitution is the code I write today should be useful 1000 years from now. But these days we have problems where code that is just a few years old is already "legacy". It's extremely wasteful and a lot of enterprises are seeing this. They don't want to make the same mistake by betting on proprietary technology they have no control over.

Bass said:

Charles said:

*snip*

The web is a royalty free standard with many different vendors (Apple, Mozilla, Microsoft, etc.) involved so it doesn't have the same lockin potential. The standards based web is open and a relatively slow moving target with extreme backwards compatibility.

 

Lockin is a disaster, it leads to software rot. Software really doesn't rot, just like the Pythagorean theorem doesn't rot. But yet many enterprises are spending millions of dollars rewriting "legacy" code that is only legacy because it was locked into some vendor's platform or product line that is either retired or doesn't exist anymore. The ideal stitution is the code I write today should be useful 1000 years from now. But these days we have problems where code that is just a few years old is already "legacy". It's extremely wasteful and a lot of enterprises are seeing this. They don't want to make the same mistake by betting on proprietary technology they have no control over.

The web is a royalty free standard with many different vendors (Apple, Mozilla, Microsoft, etc.) involved so it doesn't have the same lockin potential. The standards based web is open and a relatively slow moving target with extreme backwards compatibility.

That is true and correct only if you consider the tiny part of development that is represented by HTML/CSS/etc.

Anything that runs on the server, the vast majority of the mission-critical code, it's still absolutely victim of proprietary lock in, be it from a company, a language or a framework.

Charles said:

In some sense, we could do a better job of focusing our platform wares (how many tools does it take to do the same thing?) and highlighting the great things that are built using them. Make no mistake, Windows is a great platform to target should you want to get into the software business. Windows is a big tent and any number of applications, using any number of tools, can be written to get the most out of Windows. The question is: why has Windows client app development declined? The tooling? Maybe. What do you think?

 

C

The question is: why has Windows client app development declined?

Is it? I don't know globally, but all the companies I work with have rich clients under development, especially now that WPF is finally ramping up (of course we are beyond that, and happily shipping Silverlight 4 desktop apps )

spivonious said:

Larry Osterman said:

*snip*

I would write:

 

Sub MyFunction(input as String)

   Dim dest as String = input.Replace(".", "\.")

End Sub

 

Let the framework designers worry about algorithm performance. I just want the result.

Except, the language used is C++, and std::string doesn't have a replace method.

Well, actually, it does have one, but it doesn't do what you'd expect.

Sven Groot said:

spivonious said:

*snip*

Except, the language used is C++, and std::string doesn't have a replace method.

 

Well, actually, it does have one, but it doesn't do what you'd expect.

Boost::string_algo to the rescue!

Shining Arcanine said:

Larry Osterman said:

*snip*

Did you ask him what the computational complexity of his algorithm was? It looks O(nm) to me, while yours is O(n). When the entire string consists of '.', you can call it O(n^2).

 

By the way, dotIndex will give you a compiler warning in the second one, because it is not used.

The version with erase is is O(nm), with n the length of the string and m the number of periods.

If you take out erase like in the alternative version with find I wrote, it's O(n). Even if you use substr I still think it's O(n). Technically my version is O(2n) and the substr version is O(4n), but that's both still linear.

The erase version will reduce to O(n^2) if the string consists entirely of periods. The version without erase (with or without substr) remains O(n) regardless of the number of periods in the string.

Again, I'm not contending that Larry's second version isn't better (it is). I'm just saying that using find doesn't make it O(n^2).

If you want to get really technical, things aren't that simple anyway. Even Larry's good version is not really O(n) because push_back and append are not O(1) operations if the string needs to resize.

Bass said:

Sven Groot said:

*snip*

Boost::string_algo to the rescue!

Boost::string_algo to the rescue!

That'd be my real-world solution as well.

Sven Groot said:

Shining Arcanine said:

*snip*

The version with erase is is O(nm), with n the length of the string and m the number of periods.

If you take out erase like in the alternative version with find I wrote, it's O(n). Even if you use substr I still think it's O(n). Technically my version is O(2n) and the substr version is O(4n), but that's both still linear.

 

The erase version will reduce to O(n^2) if the string consists entirely of periods. The version without erase (with or without substr) remains O(n) regardless of the number of periods in the string.

 

Again, I'm not contending that Larry's second version isn't better (it is). I'm just saying that using find doesn't make it O(n^2).

 

If you want to get really technical, things aren't that simple anyway. Even Larry's good version is not really O(n) because push_back and append are not O(1) operations if the string needs to resize.

Sven Groot said:

If you take out erase like in the alternative version with find I wrote, it's O(n). Even if you use substr I still think it's O(n). Technically my version is O(2n) and the substr version is O(4n), but that's both still linear.

Technically, the constant is considered irrelevant when doing big O, so all three versions are O(n). Which is one of the reasons why I dislike seeing big O notation being heavily relied upon for performance analysis. And, as you say, if push_back or append aren't constant time operations then any sort of big O analysis is simply wrong.

EDIT: constant time, not linear. Coffee before posting.

Charles said:

In some sense, we could do a better job of focusing our platform wares (how many tools does it take to do the same thing?) and highlighting the great things that are built using them. Make no mistake, Windows is a great platform to target should you want to get into the software business. Windows is a big tent and any number of applications, using any number of tools, can be written to get the most out of Windows. The question is: why has Windows client app development declined? The tooling? Maybe. What do you think?

 

C

Its not the tooling for sure.  IMO MS has never been cool to a large group of IT developers but the strength of the tooling is the reason why they have so many good developers now, despite that fact.

I don't understand the ethos of cool, I recognise it but have no real interest in it (maybe thats another definition of a geek?)

Ian2 said:

Charles said:

*snip*

Its not the tooling for sure.  IMO MS has never been cool to a large group of IT developers but the strength of the tooling is the reason why they have so many good developers now, despite that fact.

 

I don't understand the ethos of cool, I recognise it but have no real interest in it (maybe thats another definition of a geek?)

The problem is I think a lot of .NET developers really haven't been exposed to anything outside of the .NET realm, and they make claims like this. I'm guilty of this as well.

I've finally been exposed professionally to something other then .NET for development, and I know now that .NET is extremely overrated. C# real strength is in the language, but no so much in the libraries. I don't think the tooling is all that competitive either (VS vs Eclipse/STS). I can't really think of a single reason why I'd use ASP.NET MVC/WebForms over J2EE/Spring from a productivity standpoint. And I've been doing .NET development for years and Java for only a few months.

Bass said:

Ian2 said:

*snip*

The problem is I think a lot of .NET developers really haven't been exposed to anything outside of the .NET realm, and they make claims like this. I'm guilty of this as well.

 

I've finally been exposed professionally to something other then .NET for development, and I know now that .NET is extremely overrated. C# real strength is in the language, but no so much in the libraries. I don't think the tooling is all that competitive either (VS vs Eclipse/STS). I can't really think of a single reason why I'd use ASP.NET MVC/WebForms over J2EE/Spring from a productivity standpoint. And I've been doing .NET development for years and Java for only a few months.

What do you think all these Microsoft developers were doing before .NET came along? All those who weren't doing Java I mean?

Java's problem is stagnation. MS has the advantage here because they don't need a committee vote to keep the language up to date. They also have the advantage of seeing the mistakes Java made (tying the class namespaces to the machine's directory structure - what the hell were they thinking??) and fixing them.

Still, the lack of a committee is why MS can keep dumping everything into the language making it more and more difficult to learn, and more and more inconsistent.

The real asset is the JVM which can accept a whole wodge of languages that are superior to Java (Scala and Groovy for starters). Oh, and IntelliJ IDEA which is quite simply the best IDE on the planet. Watch iPhone developers breath a huge sigh of relief when JetBrains release an IDE for ObjectiveC (if Apple allows them to).

Bass said:

Sven Groot said:

*snip*

Boost::string_algo to the rescue!

Or the STL...

I think what Larry is trying to determine in an interview is "does this person understand the fundamentals?". If the interviewee said "Well, I'd just use  the STL or Boost and be done with it - since I know the algorithms employed there are far better than anything I could scribble out on your whiteboard in 5 minutes....", I don't think this answer would qualify as a "pass"...

C

Bass said:

Ian2 said:

*snip*

The problem is I think a lot of .NET developers really haven't been exposed to anything outside of the .NET realm, and they make claims like this. I'm guilty of this as well.

 

I've finally been exposed professionally to something other then .NET for development, and I know now that .NET is extremely overrated. C# real strength is in the language, but no so much in the libraries. I don't think the tooling is all that competitive either (VS vs Eclipse/STS). I can't really think of a single reason why I'd use ASP.NET MVC/WebForms over J2EE/Spring from a productivity standpoint. And I've been doing .NET development for years and Java for only a few months.

Bold claims, very bold claims.

@The problem is I think a lot of .NET developers really haven't been exposed to anything outside of the .NET realm, and they make claims like this. I'm guilty of this as well.

Yes, this is true for a lot of "young" developers, but at the incipience of .NET in the real word there were a lot of C++ developers (me included). You will find that in the real world, a lot of C# developers are former C++ or VB6 developers, and most would claim that comparing Java and C# can only be done by a minor because they have used a variety of languages and tools before .NET

@ I've finally been exposed professionally to something other then .NET for development, and I know now that .NET is extremely overrated. C# real strength is in the language, but no so much in the libraries. I don't think the tooling is all that competitive either (VS vs Eclipse/STS). I can't really think of a single reason why I'd use ASP.NET MVC/WebForms over J2EE/Spring from a productivity standpoint. And I've been doing .NET development for years and Java for only a few months.

Come back and update this thread when you have been using Java after a few years, and you will find that you were comparing a "bramley apple" to a "granny smiths".

I have used Java and .NET both and both are suited to some problems better than others, but there is overlap, and you are at the stage where you only critique the overlap, and are unable to deduce or make the call as to why you would use one over the other, but are voiciferous about the aforementioned minutae.

Sven Groot said:

Shining Arcanine said:

*snip*

The version with erase is is O(nm), with n the length of the string and m the number of periods.

If you take out erase like in the alternative version with find I wrote, it's O(n). Even if you use substr I still think it's O(n). Technically my version is O(2n) and the substr version is O(4n), but that's both still linear.

 

The erase version will reduce to O(n^2) if the string consists entirely of periods. The version without erase (with or without substr) remains O(n) regardless of the number of periods in the string.

 

Again, I'm not contending that Larry's second version isn't better (it is). I'm just saying that using find doesn't make it O(n^2).

 

If you want to get really technical, things aren't that simple anyway. Even Larry's good version is not really O(n) because push_back and append are not O(1) operations if the string needs to resize.

It can be shown that there is no real penalty for resize-able arrays if they double in size when they are expanded and shrink in size only when the capacity used is less than 1/4 the size of the array, so saying that the string needs to resize is a non-issue assuming it is implemented in this way. As a result, the resize operations can be ignored and those functions are amortized O(1) time.

By the way, it is interesting to note that this algorithm is similar to quicksort, where quicksort is O(nlogn) in the average case, but in the worst case, it becomes an insertion sort, which is O(n^2).

Edit: I noticed that you were talking about this same thing before my post. I feel silly now. Anyway, the problem screams for the use of a theoretical turing machine. In which case, you would think in terms of the machine reading an input tape and writing to an output tape. In that manner, it can have stages {0,1,EOF}. Stage 0 is the starting state. From state zero, the state transistion function can go multiple ways. Here is a list of rule sin the state transition function:

• From state 0, upon seeing a symbol '/0', the machine will write '/0' to the output tape, advance both tape heads and move to state EOF.
• From state 0, upon seeing a symbol '.', the machine will write '/' to the output tape, advance both tape heads and move to state 1.
• From state 1, the machine will output '.', advance the output tape head and move to state 0.
• From state 0, upon seeing a symbol c in the input tape, where c is not '/0' and not '.', the machine will write c to the output tape, advance both the input and output tapes and return to state 0. Obviously, this rule is actually n - 2 rules, where n is the number of characters allowed in the character set.

Larry's second code example is a good approximation of this in C++.

vesuvius said:

Bass said:

*snip*

Bold claims, very bold claims.

 

@The problem is I think a lot of .NET developers really haven't been exposed to anything outside of the .NET realm, and they make claims like this. I'm guilty of this as well.

 

Yes, this is true for a lot of "young" developers, but at the incipience of .NET in the real word there were a lot of C++ developers (me included). You will find that in the real world, a lot of C# developers are former C++ or VB6 developers, and most would claim that comparing Java and C# can only be done by a minor because they have used a variety of languages and tools before .NET

 

@ I've finally been exposed professionally to something other then .NET for development, and I know now that .NET is extremely overrated. C# real strength is in the language, but no so much in the libraries. I don't think the tooling is all that competitive either (VS vs Eclipse/STS). I can't really think of a single reason why I'd use ASP.NET MVC/WebForms over J2EE/Spring from a productivity standpoint. And I've been doing .NET development for years and Java for only a few months.

 

Come back and update this thread when you have been using Java after a few years, and you will find that you were comparing a "bramley apple" to a "granny smiths".

 

I have used Java and .NET both and both are suited to some problems better than others, but there is overlap, and you are at the stage where you only critique the overlap, and are unable to deduce or make the call as to why you would use one over the other, but are voiciferous about the aforementioned minutae.

For some things I still think .NET makes more sense, like if I was doing Windows fat clients or something. But really the most impressive client software I've seen from a 9'er was apperently written in Delphi. Go figure.

Charles said:

Bass said:

*snip*

Or the STL...

 

I think what Larry is trying to determine in an interview is "does this person understand the fundamentals?". If the interviewee said "Well, I'd just use  the STL or Boost and be done with it - since I know the algorithms employed there are far better than anything I could scribble out on your whiteboard in 5 minutes....", I don't think this answer would qualify as a "pass"...

C

The thing is that the algorithms used in the STL or Boost libraries are only better under the circumstances for which they were designed. When they exist as a tiny piece of a much larger whole, arbitrarily stitching them together typically produces a slow algorithm. People need to work out exactly how an the higher level algorithm should work, break it into its fundamental building blocks and then implement it in a way that reuses as much existing code as possible, rather than trying to glue a bunch of library functions to get my desired result.

Bass said:

vesuvius said:

*snip*

For some things I still think .NET makes more sense, like if I was doing Windows fat clients or something. But really the most impressive client software I've seen from a 9'er was apperently written in Delphi. Go figure.

What is most impressive are the problems you solve with whichever tools you have at your disposal. Some people work at at Microsoft for ages, and inevitably solve problems that are visible by the many millions. Some people write software that  helps protects millions of people whether physical or virtual. Some people write software that helps people get to anywhere they want to in a motor vehicle. Others write software that controls airports, others write software that ensures that you can go to a shop and find goods that improve your life

Frameworks and programming languages are essential, but unless you are solving problems and improving peoples lives then you end up comparing VB6 with Haskell. I think it was Oscar Wilde that wrote "nothing that actually occurs is of the littlest importance" or words to that effect.

DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS!!!!!

\

vesuvius said:

Bass said:

*snip*

What is most impressive are the problems you solve with whichever tools you have at your disposal. Some people work at at Microsoft for ages, and inevitably solve problems that are visible by the many millions. Some people write software that  helps protects millions of people whether physical or virtual. Some people write software that helps people get to anywhere they want to in a motor vehicle. Others write software that controls airports, others write software that ensures that you can go to a shop and find goods that improve your life

 

Frameworks and programming languages are essential, but unless you are solving problems and improving peoples lives then you end up comparing VB6 with Haskell. I think it was Oscar Wilde that wrote "nothing that actually occurs is of the littlest importance" or words to that effect.

I think libraries are more important than frameworks, which are merely glorified collections of libraries. You could call POSIX a framework and you would not be wrong to say that, but it is really libraries that matter.

Charles said:

Bass said:

*snip*

Or the STL...

 

I think what Larry is trying to determine in an interview is "does this person understand the fundamentals?". If the interviewee said "Well, I'd just use  the STL or Boost and be done with it - since I know the algorithms employed there are far better than anything I could scribble out on your whiteboard in 5 minutes....", I don't think this answer would qualify as a "pass"...

C

The STL doesnt't have a string replacement function. That was sort of the point of recommending boost.

Shining Arcanine said:

Sven Groot said:

*snip*

It can be shown that there is no real penalty for resize-able arrays if they double in size when they are expanded and shrink in size only when the capacity used is less than 1/4 the size of the array, so saying that the string needs to resize is a non-issue assuming it is implemented in this way. As a result, the resize operations can be ignored and those functions are amortized O(1) time.

 

By the way, it is interesting to note that this algorithm is similar to quicksort, where quicksort is O(nlogn) in the average case, but in the worst case, it becomes an insertion sort, which is O(n^2).

 

Edit: I noticed that you were talking about this same thing before my post. I feel silly now. Anyway, the problem screams for the use of a theoretical turing machine. In which case, you would think in terms of the machine reading an input tape and writing to an output tape. In that manner, it can have stages {0,1,EOF}. Stage 0 is the starting state. From state zero, the state transistion function can go multiple ways. Here is a list of rule sin the state transition function:

 

• From state 0, upon seeing a symbol '/0', the machine will write '/0' to the output tape, advance both tape heads and move to state EOF.
• From state 0, upon seeing a symbol '.', the machine will write '/' to the output tape, advance both tape heads and move to state 1.
• From state 1, the machine will output '.', advance the output tape head and move to state 0.
• From state 0, upon seeing a symbol c in the input tape, where c is not '/0' and not '.', the machine will write c to the output tape, advance both the input and output tapes and return to state 0. Obviously, this rule is actually n - 2 rules, where n is the number of characters allowed in the character set.

 

Larry's second code example is a good approximation of this in C++.

It can be shown that there is no real penalty for resize-able arrays if they double in size when they are expanded

Source? Your statement contradicts my own experience.

Sven Groot said:

Shining Arcanine said:

*snip*

Source? Your statement contradicts my own experience.

Hey probably meant by doubling the array size every time you need to enlarge the array makes trivial performance impact.

Kinda no duh.

Minh said:

Sven Groot said:

*snip*

Hey probably meant by doubling the array size every time you need to enlarge the array makes trivial performance impact.

Kinda no duh.

Still contradicts my own experience. I've had algorithms where the cost of array resizing was a significant part of the overall time taken, despite the fact that I was doubling it every time.

Not to mention issues of wasted space and heap fragmentation that can occur with resizing. Yes, you can minimize the impact of resizing by picking an appropriate growth factor (and depending on the algorithm, 2 isn't always the best option), but it's still not free, it's still not O(1), and you should definitely not assume it has "no real penalty" without first measuring it.

Sven Groot said:

Minh said:

*snip*

Still contradicts my own experience. I've had algorithms where the cost of array resizing was a significant part of the overall time taken, despite the fact that I was doubling it every time.

 

Not to mention issues of wasted space and heap fragmentation that can occur with resizing. Yes, you can minimize the impact of resizing by picking an appropriate growth factor (and depending on the algorithm, 2 isn't always the best option), but it's still not free, it's still not O(1), and you should definitely not assume it has "no real penalty" without first measuring it.

What were you doing?

I figure resizing wouldn't have zero impact... but doubling it does a decent job at performance at the cost of space

Minh said:

Sven Groot said:

*snip*

What were you doing?

 

I figure resizing wouldn't have zero impact... but doubling it does a decent job at performance at the cost of space

I was dealing with a very large number of resizable arrays. It was essentially a tree-like structure where the resizable arrays were used to contain the child pointers of each node. I did try some alternatives but everything I came up with was even slower than the resizable arrays.

Sven Groot said:

Minh said:

*snip*

I was dealing with a very large number of resizable arrays. It was essentially a tree-like structure where the resizable arrays were used to contain the child pointers of each node. I did try some alternatives but everything I came up with was even slower than the resizable arrays.

Hmmm... Arrays implemented by linked list?

Minh said:

Sven Groot said:

*snip*

Hmmm... Arrays implemented by linked list?

I did try linked lists of course, but it was too slow. We're talking several orders of magnitude slower than the array version here.

Sven Groot said:

Minh said:

*snip*

I did try linked lists of course, but it was too slow. We're talking several orders of magnitude slower than the array version here.

slower in access? Maybe pre-computed "index" access?

Minh said:

Sven Groot said:

*snip*

slower in access? Maybe pre-computed "index" access?

Linked Lists are horribly slow. They don't work well with caches and every time you dereference a pointer, you run the risk of a page fault and page faults are very, very expensive.

Charles said:

Bass said:

*snip*

Or the STL...

 

I think what Larry is trying to determine in an interview is "does this person understand the fundamentals?". If the interviewee said "Well, I'd just use  the STL or Boost and be done with it - since I know the algorithms employed there are far better than anything I could scribble out on your whiteboard in 5 minutes....", I don't think this answer would qualify as a "pass"...

C

*ding* *ding* *ding*  Give the man a ceegar.

It's about understanding the fundamentals (I once had someone say "Just use vector.reverse()" to reverse a linked list).

This is where fundamentals come in: Write efficient code always.  Don't hyper-optimize your code (unless you have evidence that shows that the code is a bottleneck), but always write code which is tight.  

Of course there are caveats: Don't sacrifice readability.  Ever.  In production code, it is absolutely reasonable to use vector.reverse() instead of hand rolling reverse.  Or use String.Replace() if you're running under the CLR.

But you should always be able to determine the inherent inefficiency of using substr to extract elements from a string and erase to advance a pointer.

PS: You're all right that it's O(nm) where n is the length of the string and m is the # of . characters.  Which is still worse than it has to be.

Bass said:

Ian2 said:

*snip*

The problem is I think a lot of .NET developers really haven't been exposed to anything outside of the .NET realm, and they make claims like this. I'm guilty of this as well.

 

I've finally been exposed professionally to something other then .NET for development, and I know now that .NET is extremely overrated. C# real strength is in the language, but no so much in the libraries. I don't think the tooling is all that competitive either (VS vs Eclipse/STS). I can't really think of a single reason why I'd use ASP.NET MVC/WebForms over J2EE/Spring from a productivity standpoint. And I've been doing .NET development for years and Java for only a few months.

Not true, Bass. The vast majority will have exposure to Web development - at least some Javascript and possibly PHP. That means, essentially functional programming and higher-order functions at their fingertips. Then, depending on your age, you're very likely to have had experience with Java and the Java Platform. I can't imagine anyone using these forums to fit your stereotype and now apparently, neither do you.

Now that you say that .NET is overrated, what do you mean precisely. Do you have specific examples of frameworks, namespaces and types that you think are inferior and inferior compared to what - and why?

To me, the implication of the statement that C# is a great language must necessarily be that it can be used to create great frameworks. That doesn't automagically always lead to great frameworks, of course, but it should steer you in the right direction. Great languages usually have equally great libraries.

I've always been somewhat unimpressed by the .NET collections namespaces, when compared to the Java Collections library in terms of depth but a feature of C#, that primitive types are automatically boxed and unboxed is really great for collections. And with C# 2.0 generics, a List<int> will not have the boxing overhead. So you get both performance and abstraction whereas, at least historically, in Java, you've had to create specialized collection types for different native types. I believe there is a GNU Java library that does this, Trove or some such. That's clearly inferior - and critically so, as collections is at the heart of both .NET and Java, or any platform really.

Let's also take the Java iterator interface. Erik Meijer has already taken that interface to pieces but it's unnecessarily bloated and does too much. With Reactive Extensions for .NET there is now also a mathematical dual of IEnumerable, the new IObservable. IEnumerable is also greatly integrated into C# via the iterator state machine feature (although there are some performance woes here in some scenarios.) It's that kind of deep analysis that creates great libraries and languages.

Let's also not forget LINQ!  - monadic queries over arbitrary structures. The Java community may have some copy-cat efforts here but was definitely not first in this game (nothing wrong with copying though). Then there's VB and C# language support. It's a superb and pervasive feature set.

I hope in the future we'll see a large immutable collections library in .NET.

The real challenge for .NET, is probably not Java but JVM-"biased" languages such as Scala, that are more advanced than C# and facilitate very coherent, advanced and elegant libraries , much more sophisticated than traditional Java Platform libraries. On the other hand it may be too advanced for many developers.

Larry Osterman said:

Charles said:

*snip*

*ding* *ding* *ding*  Give the man a ceegar.

 

It's about understanding the fundamentals (I once had someone say "Just use vector.reverse()" to reverse a linked list).

 

This is where fundamentals come in: Write efficient code always.  Don't hyper-optimize your code (unless you have evidence that shows that the code is a bottleneck), but always write code which is tight.  

 

Of course there are caveats: Don't sacrifice readability.  Ever.  In production code, it is absolutely reasonable to use vector.reverse() instead of hand rolling reverse.  Or use String.Replace() if you're running under the CLR.

 

But you should always be able to determine the inherent inefficiency of using substr to extract elements from a string and erase to advance a pointer.

 

 

PS: You're all right that it's O(nm) where n is the length of the string and m is the # of . characters.  Which is still worse than it has to be.

 

I understand that in an interview, it's about testing fundamentals. But personally, if I were interviewing someone, I'd appreciate it if they'd say "in real life, I'd use this library method" in addition to given the proper answer. Because it'd demonstrate that they're aware that reinventing the wheel isn't something you want to do in production code.

Yes, they have to be able to write the code, and know the fundamentals, and it's perfectly fine to ask them to do that during an interview. But imo, they also have to know that in real life, it's better to rely on other people's expertise in some cases. Don't write your own string replacement algorithm unless you've demonstrated that the one from whatever library you're using doesn't meet your needs.

Now, if I were in an interview and had been asked that question, the code I actually would've written would've been this:

string MyFunction(const string &input)
{
  string dest;
  dest.reserve(input.size());
  for( string::const_iterator it = input.begin(); it != input.end(); ++it )
  {
    if( *it == '.' )
      dest.push_back('\\');
    dest.push_back(*it);
  }

  return dest;
}

This helps reduce the number of resizes necessary by reserving a reasonable capacity up front (note it will still need one resize if the input contains periods; if anything was specified about the input data I might decide to reserve a capacity larger than input.size()), and it uses iterators because it's a) safer than pointers and b) the string class allows embedded \0 characters, something that Larry's version didn't handle.

Sven Groot said:

Shining Arcanine said:

*snip*

Source? Your statement contradicts my own experience.

My algorithms professor said that if you start at 1 and keep doubling, the number of copies you do is 2n, where n is the size of the final array and concluded that there is no performance penalty to having resizeable arrays, because O(2n) = O(n).

I guess since memory allocation is something like a cubic algorithm, the number of allocations, log(n), also would play a role, so the act of allocation dominates the time complexity over the act of copying, but you can cheat by doing allocations on the stack, making the copies dominate.

Of course, if you use Java, then you are stuck with slow dynamic memory allocations. Does anyone know if the same is true for .NET?

Shining Arcanine said:

Sven Groot said:

*snip*

My algorithms professor said that if you start at 1 and keep doubling, the number of copies you do is 2n, where n is the size of the final array and concluded that there is no performance penalty to having resizeable arrays, because O(2n) = O(n).

 

I guess since memory allocation is something like a cubic algorithm, the number of allocations, log(n), also would play a role, so the act of allocation dominates the time complexity over the act of copying, but you can cheat by doing allocations on the stack, making the copies dominate.

 

Of course, if you use Java, then you are stuck with slow dynamic memory allocations. Does anyone know if the same is true for .NET?

Hrm... no performance penalty in having resizeable arrays? What a joke. Yes, doubling the size of the array on resize is better than increasing the size by a constant value. But that doesn't imply that there's no performance penalty. As you noted already you have to allocate a new block of memory (though I'd say that "cubic" is a bit much...) and you have to copy the old array contents. And then there's the problem of wasted memory space...

As for .NET memory allocations: depends what you call memory allocation in this case. If you include the garbage collection time then yes, memory allocation can be slow. But you have to remember that garbage collection runs only from time to time. It doesn't run on every allocation. If there's enough free memory available then memory allocation in .NET is as simple as incrementing a pointer.

Shining Arcanine said:

Sven Groot said:

*snip*

My algorithms professor said that if you start at 1 and keep doubling, the number of copies you do is 2n, where n is the size of the final array and concluded that there is no performance penalty to having resizeable arrays, because O(2n) = O(n).

 

I guess since memory allocation is something like a cubic algorithm, the number of allocations, log(n), also would play a role, so the act of allocation dominates the time complexity over the act of copying, but you can cheat by doing allocations on the stack, making the copies dominate.

 

Of course, if you use Java, then you are stuck with slow dynamic memory allocations. Does anyone know if the same is true for .NET?

Besides the allocation and copying, there is potentially wasted space (and the larger your growth rate, the worse that will get), heap fragmentation, and potentially additional cache misses. In a managed environment such as Java or .Net there is also the costs of zero-initializing the re-allocated array as well as added GC pressure (although this will likely be negligable).

Yes, in many cases this won't make much difference. But in some rare cases, it might. Never make assumptions, and always measure before you optimize.

jamie said:

ManipUni said:

*snip*

for us it was different .... all design students - in all colleges - are taught on MACs - illustrator.

 

we were a web shop - and pc design ad shop.  the photoshop work learned was good - but illustrator in our world is like a word perfect file in a word shop = akkk!

 

the only thing i hate more than ballmer is illustrator    bloated eps - die! die! die!

 

* i agree with jobs again = adobe SUCKS  (eps = die   PFB = die  FLV = die etc)

 

I learned Illustrator several years ago in a course at a local community college whose lab and classrooms computers are PCs using Windows XP. The college has one classrom that uses Apple computers.

The challenge is the college's  Multimedia department uses mostly  the latest version of Adobe applications including Photoshop, Illustrator, Flash, Dreamweaver, and Premiere Pro and teaches JavaScript and PHP programming.

The Computer Science department teaches C++ and Java  programming and does not use Visual Studio and therefore does not teach either C# or VB in its programming coures.

Eight to twelve years ago this same college taught Visual Basic using Visual Studio.

While I have asked the college for several years to teach courses using Expression Studio, Visual Studio  and SQL Server they simply do not have the budget to support credit courses with this software.

Microsoft must provide the software for at least three years to the local colleges or they will continue to be frozen out by Adobe applications, the Open Source crowd, and C++ , Java and PHP programming languages.

Microsoft giving  the software away for free to students is a great idea.

Unfortunately, many colleges remain locked in to Adobe applications for implementing web sites with the JavaScript and PHP programming languages.

Looks like the same college might be teaching an ASP.NET in the spring.

However, to date they do not have the budget for buying Visual Studio and SQL Server.

Forget about them buying Expression Studio.

Suggest Microsoft give colleges for a period of five years the latest versions of Visual Studio, Expression Studio and SQL Server for free and have Microsoft Evangelists actively promote this and the free student software to as many colleges and universities as possible.

For young students wanting to become web designers and web deveopers, many local colleges are not exposing students to Microsoft's applications for the simple reason they do not have the money to buy Microsoft software in addition to Adobe's.

Young and hip college students are in many instances not even aware of Microsoft Expression Studio and Visual Studio existence.

What we have here is a failure to communicate.

http://www.youtube.com/watch?v=l_aVuS7cOIQ

Sven Groot said:

Charles said:

*snip*

The STL doesnt't have a string replacement function. That was sort of the point of recommending boost.

You are such a stickler, man.... Whatever. My point was made...

C

raymond said:

jamie said:

*snip*

 

 

I learned Illustrator several years ago in a course at a local community college whose lab and classrooms computers are PCs using Windows XP. The college has one classrom that uses Apple computers.

 

The challenge is the college's  Multimedia department uses mostly  the latest version of Adobe applications including Photoshop, Illustrator, Flash, Dreamweaver, and Premiere Pro and teaches JavaScript and PHP programming.

 

The Computer Science department teaches C++ and Java  programming and does not use Visual Studio and therefore does not teach either C# or VB in its programming coures.

 

Eight to twelve years ago this same college taught Visual Basic using Visual Studio.

 

While I have asked the college for several years to teach courses using Expression Studio, Visual Studio  and SQL Server they simply do not have the budget to support credit courses with this software.

 

Microsoft must provide the software for at least three years to the local colleges or they will continue to be frozen out by Adobe applications, the Open Source crowd, and C++ , Java and PHP programming languages.

 

Microsoft giving  the software away for free to students is a great idea.

 

Unfortunately, many colleges remain locked in to Adobe applications for implementing web sites with the JavaScript and PHP programming languages.

 

Looks like the same college might be teaching an ASP.NET in the spring.

 

However, to date they do not have the budget for buying Visual Studio and SQL Server.

 

Forget about them buying Expression Studio.

 

Suggest Microsoft give colleges for a period of five years the latest versions of Visual Studio, Expression Studio and SQL Server for free and have Microsoft Evangelists actively promote this and the free student software to as many colleges and universities as possible.

 

For young students wanting to become web designers and web deveopers, many local colleges are not exposing students to Microsoft's applications for the simple reason they do not have the money to buy Microsoft software in addition to Adobe's.

 

Young and hip college students are in many instances not even aware of Microsoft Expression Studio and Visual Studio existence.

 

What we have here is a failure to communicate.

 

http://www.youtube.com/watch?v=l_aVuS7cOIQ

raymond said:

While I have asked the college for several years to teach courses using Expression Studio, Visual Studio  and SQL Server they simply do not have the budget to support credit courses with this software.

You should point them in the direction of the MSDN Academic Alliance program. It's not free, but it is unbelievably cheap and a fantastic way of providing those kinds of tools to support education.

AndyC said:

raymond said:

*snip*

You should point them in the direction of the MSDN Academic Alliance program. It's not free, but it is unbelievably cheap and a fantastic way of providing those kinds of tools to support education.

MSDNAA is free for every IT student in Belgium.

Sven Groot said:

Shining Arcanine said:

*snip*

Besides the allocation and copying, there is potentially wasted space (and the larger your growth rate, the worse that will get), heap fragmentation, and potentially additional cache misses. In a managed environment such as Java or .Net there is also the costs of zero-initializing the re-allocated array as well as added GC pressure (although this will likely be negligable).

 

Yes, in many cases this won't make much difference. But in some rare cases, it might. Never make assumptions, and always measure before you optimize.

Big Oh notation ignores wasted space and cache misses. Optimizations should focus on computational complexity first and "tuning" (e.g. loop invariant code motion) second.

By the way, you could run an algorithm O(nlogn) algorithm on a system that has no cache and have it outperform a system that has oodles of cache that is running a O(n^2) algorithm. You just need to increase the input size and it follows from limit laws in Calculus that the lower complexity algorithm will be faster. Hacks like a cache or compiler optimizations will not change that.

ZippyV said:

AndyC said:

*snip*

MSDNAA is free for every IT student in Belgium.

Is Microsoft only offering it for free in Belgium or do other countries get the software for free too? If the Belgian government is subsidizing it, it really is not free, even though the costs are hidden from the university.

Also we're hitting at point where a lot of them don't want/desire to work for large companies but instead start their own *garage companies* and/or work in small teams.

Like when you look at a lot of the "popular" projects coming out...twitter, facebook, etc...while they're not necessarily popular for a lot of programmers,...it's a generational thing...they're obviously very popular and widely used.  None of those things are SEEMINGLY made with microsoft OR even 'apple'.  Yes they may run OS, Apple, etc(I use linux exclusively for the last 3 years strangely enough).  They just want to get it done.  They want to make a cool project and by that I don't mean a 3d robot emulator or some project that manipulates your clipboard.  They want 'social' projects...so I think that's where the 'scare' articles are going.  Honestly the way that I see it...and this is hard to explain so it's going to come out awful...  There seems to be "creative artist type that also decides to learn to program to make what he imagines" vs a "scientist or engineer" type battle.  You have the guy that knows .NET very well and is excited about adding a certain encryption to his authentication system and then you have someone that wants to 'start' the next facebook.  The funny thing is both types need each other.  Apple isn't really in the battle because they have their small niche of 'nuts'.  Unless you're working on a ipod/ipad application, etc...you're not using XCode and you're not spending $100 to HAVE THE RIGHTS TO LEARN HOW TO USE THE TOOL.  As for M$ tools...they're so widely used they're not going anywhere BUT it would be a good idea for them to start looking at a more open arena *which they are* and aim more at not just a microsoft crowd but one that allows people to build for whatever/where ever they want. Like if anyone watched Googles I/O conference yes they bragged and tooted the google horn but a lot of the really cool stuff had nothing to do with google and more so html5(which yes google has it's hands on), javascript, etc and the fact that operating systems may play a much smaller role soon.  [breathes...ok my rants over. there's my .30 cents, lol]

Shining Arcanine said:

Sven Groot said:

*snip*

Big Oh notation ignores wasted space and cache misses. Optimizations should focus on computational complexity first and "tuning" (e.g. loop invariant code motion) second.

 

By the way, you could run an algorithm O(nlogn) algorithm on a system that has no cache and have it outperform a system that has oodles of cache that is running a O(n^2) algorithm. You just need to increase the input size and it follows from limit laws in Calculus that the lower complexity algorithm will be faster. Hacks like a cache or compiler optimizations will not change that.

Which is why Big O notation isn't the end-all of performance evaluation that some people think it is.

If you go strictly by Big O notation, both Larry's second version of the string replacement algorithm and my alternative version with find are O(n). Yet Larry's version is obviously faster.

Big O ignores the constants which makes it of only very limited use in real world optimization.

Charles said:

Sven Groot said:

*snip*

You are such a stickler, man.... Whatever. My point was made...

C

The devil's in the details.

Shining Arcanine said:

ZippyV said:

*snip*

Is Microsoft only offering it for free in Belgium or do other countries get the software for free too? If the Belgian government is subsidizing it, it really is not free, even though the costs are hidden from the university.

I've heard rumors that Microsoft developers like to get paid for their efforts to aquire luxuries like food and shelter. - But sure, that just means it isn't free for Microsoft!

That said, it makes perfect sense to pour free or inexpensive software on academia to capitalize on research and gain mind share.

Sven Groot said:

Charles said:

*snip*

The STL doesnt't have a string replacement function. That was sort of the point of recommending boost.

Devil's in the details?

#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>

using namespace std;


int main()
{
    const int VECTOR_SIZE = 8 ;

    // Define a template class vector of integers
    typedef vector<int > IntVector ;

    //Define an iterator for template class vector of integer
    typedef IntVector::iterator IntVectorIt ;

    IntVector Numbers(VECTOR_SIZE) ;   //vector containing numbers

    IntVectorIt start, end, it ;

    start = Numbers.begin() ;   // location of first
                                // element of Numbers

    end = Numbers.end() ;       // one past the location
                                // last element of Numbers

    //Initialize vector Numbers
    Numbers[0] = 10 ;
    Numbers[1] = 20 ;
    Numbers[2] = 10 ;
    Numbers[3] = 15 ;
    Numbers[4] = 12 ;
    Numbers[5] = 7 ;
    Numbers[6] = 9 ;
    Numbers[7] = 10 ;

    cout << "Before calling replace" << endl ;

    // print content of Numbers
    cout << "Numbers { " ;
    for(it = start; it != end; it++)
        cout << *it << " " ;
    cout << " }\n" << endl ;

    // remove all elements from Numbers that match 10
     replace(start, end, 10, 35) ;

    cout << "After calling replace, to replace all 10's with 35" << endl ;

    // print content of Numbers
    cout << "Numbers { " ;
    for(it = start; it != end; it++)
        cout << *it << " " ;
    cout << " }\n" << endl ;

}

C

Charles said:

Sven Groot said:

*snip*

Devil's in the details?

 

#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>

using namespace std;


int main()
{
    const int VECTOR_SIZE = 8 ;

    // Define a template class vector of integers
    typedef vector<int > IntVector ;

    //Define an iterator for template class vector of integer
    typedef IntVector::iterator IntVectorIt ;

    IntVector Numbers(VECTOR_SIZE) ;   //vector containing numbers

    IntVectorIt start, end, it ;

    start = Numbers.begin() ;   // location of first
                                // element of Numbers

    end = Numbers.end() ;       // one past the location
                                // last element of Numbers

    //Initialize vector Numbers
    Numbers[0] = 10 ;
    Numbers[1] = 20 ;
    Numbers[2] = 10 ;
    Numbers[3] = 15 ;
    Numbers[4] = 12 ;
    Numbers[5] = 7 ;
    Numbers[6] = 9 ;
    Numbers[7] = 10 ;

    cout << "Before calling replace" << endl ;

    // print content of Numbers
    cout << "Numbers { " ;
    for(it = start; it != end; it++)
        cout << *it << " " ;
    cout << " }\n" << endl ;

    // remove all elements from Numbers that match 10
     replace(start, end, 10, 35) ;

    cout << "After calling replace, to replace all 10's with 35" << endl ;

    // print content of Numbers
    cout << "Numbers { " ;
    for(it = start; it != end; it++)
        cout << *it << " " ;
    cout << " }\n" << endl ;

}

 

 

 

C

Details indeed. Look at those functions, and tell me what they do. Then look at what Larry's code does (or what .Net's String.Replace does).

Yes, the STL string class has a function named "replace", but it doesn't do what was asked for. I even already said this earlier in the thread.

Sven Groot said:

Shining Arcanine said:

*snip*

Which is why Big O notation isn't the end-all of performance evaluation that some people think it is.

 

If you go strictly by Big O notation, both Larry's second version of the string replacement algorithm and my alternative version with find are O(n). Yet Larry's version is obviously faster.

 

Big O ignores the constants which makes it of only very limited use in real world optimization.

I think another issue with Big-O notation in real life application is that most of the time, we say something like resizing on average has little impact over time as n approaches infinity.

But, you usually know n or at least have a sense of what n will be under a given scenario. If you were to plot on a graph the growth rate of different pieces of an algorithm, you need not look at where the plot ends with very large n. You would deal with some fixed frame at the very beginning of the plot, which might look completely different than what you would see with large n. In the case with resizing, it does have a performance impact for small n which probably should not be overlooked.

Sven Groot said:

Charles said:

*snip*

Details indeed. Look at those functions, and tell me what they do. Then look at what Larry's code does (or what .Net's String.Replace does).

 

Yes, the STL string class has a function named "replace", but it doesn't do what was asked for. I even already said this earlier in the thread.

True. However, I was just being a stickler on your unequivocal statement "The STL doesnt't have a string replacement function".

So there.

C