Apresentação feita na disciplina de Linguagem de progração da Universidade Federal de Juiz de Fora.

2. Linguagem de programação
C#
Adriele Alvarenga
Claudson Oliveira

3. Histórico
• C#
– Surgimento: 2001
– Influências: Java, C++ , Object pascal, etc...

4. Histórico
• C#
– Surgimento: 2001
– Influências: Java, C++ , Object pascal, etc...
– Anders Hejlsberg (Turbo pascal e Borland Delphi)

5. Histórico
• C#
– Surgimento: 2001
– Influências: Java, C++ , Object pascal, etc...
– Anders Hejlsberg (Turbo pascal e Borland Delphi)
– Objetivo: Plataforma .NET

6. Características
• Normalizada (ECMA 334 e ISO/IEC 23270)

7. Características
• Normalizada (ECMA 334 e ISO/IEC 23270)
• Orientada a objetos

8. Características
• Normalizada (ECMA 334 e ISO/IEC 23270)
• Orientada a objetos
• Compilação

9. Características
• Normalizada (ECMA 334 e ISO/IEC 23270)
• Orientada a objetos
• Compilação
• Visual Studio ou C# Express

10. Propriedades
• Legibilidade e Redigibilidade

11. Propriedades
• Legibilidade e Redigibilidade
– Baseada em C++ e Java

12. Propriedades
• Legibilidade e Redigibilidade
– Baseada em C++ e Java
public class Hello1
{
public static void Main()
{
System.Console.WriteLine("Hello, World!");
}
}

13. Propriedades
• Confiabilidade
– Tratamento de exceções

14. Propriedades
• Confiabilidade
– Tratamento de exceções
– Utilização de ponteiros (unsafe)

15. Propriedades
• Confiabilidade
– Tratamento de exceções
– Utilização de ponteiros (unsafe)
– Coletor de lixo

16. Propriedades
• Confiabilidade
– Tratamento de exceções
– Utilização de ponteiros (unsafe)
– Coletor de lixo

17. Propriedades
• Confiabilidade
– Tratamento de exceções
– Utilização de ponteiros (unsafe)
– Coletor de lixo
unsafe static void usandoPonteiros(int* p)
{
int numero = 4;
p = &numero ;
}

18. Coletor de lixo
• Gerência de memória da Heap

19. Coletor de lixo
• Gerência de memória da Heap
• Biblioteca Win32

20. Coletor de lixo
• Gerência de memória da Heap
• Biblioteca Win32

21. Coletor de lixo
• Gerência de memória da Heap
• Biblioteca Win32
• Busca linear

22. Coletor de lixo
• Gerência de memória da Heap
• Biblioteca Win32
• Busca linear

23. Coletor de lixo
• Memória dividida

24. Propriedades
• Ortogonalidade
– Permite uso dos conceitos básicos

25. Propriedades
• Ortogonalidade
– Permite uso dos conceitos básicos
– Poucas exceções
• Ponteiros para void, array do tipo void

26. Propriedades
• Eficiência
– .NET
• Just-in-time

27. Propriedades
• Eficiência
– .NET
• Just-in-time
• Compilação híbrida

28. Propriedades
• Eficiência
– .NET
• Just-in-time
• Compilação híbrida
• Otimização de instruções

29. Propriedades
• Portabilidade
– dotGNU

30. Propriedades
• Portabilidade
– dotGNU
– Portable .NET

31. Propriedades
• Portabilidade
– dotGNU
– Portable .NET
– Mono (Novell)

32. Propriedades
• Portabilidade
– dotGNU
– Portable .NET
– Mono (Novell)

33. Entrevista

34. Entrevista
How long is the future of C#? You’ve been on it for almost 10
years.
C# the project started in late December of ‘98, so we’re coming up on our 10-year
anniversary. That’s not 10 years of existing in the industry, but it’s 10 years since
inception internally. I’d say we’ve got another 10 years at least, but it all depends.
I’ve said
I’ve long given up predicting the far-off future of this industry because no one ever
gets it
right anyway. But I certainly see a strong healthy future for C#. We’re not done
innovat-ing, and there’s plenty of work still to do.

35. Entrevista
Do you get feedback regarding the C# language, not just the
implementation?
(…) I read people’s blogs, I read forums where people ask technical
questions, go to conferences—all sorts of ways that we get feedback daily
on what works and what doesn’t in the language. We take that feedback
back to the design team and we maintain a long laundry list of all of the
crazy ideas. Some of them will never make it into the lan-guage, but we
keep them on the list because there’s something there that maybe someday
we’ll get a good idea around this area. We know that we don’t have it right
yet, but there’s a desire to do something. Certainly there’s no way we could
design the language without all this feedback, so it’s all based on listening to
what people do with
the product.

36. Entrevista
When I compare C# to Java, C# seems to have a stronger push
toward evolution. The Java people seem to want a baseline
where everyone’s code looks more or less the same. Whether
you’ve programmed Java for a decade, never programmed
before, or just graduated from a six-month course on Java, all
of your code will look the same. C# seems to pull in new ideas
from Haskell or from F#. Is there a desire to add new features
that people who’ve just finished the six-month C# course
haven’t seen and won’t immediately understand?

37. Entrevista
I am not in this to engineer the next COBOL; let’s just put it that way.
What is it that powers the Internet revolution and the electronic revolution
that we’ve seen? It’s the fact that we’re constantly evolving. I bring it back
to that. The minute you stop evolving, I don’t know that you’re adding any
value. This is, again, taking it to the extreme. Of course, there is value in
stability of the platform, but I think you provide that value by ensuring
backward compatibility. You are free to get off the bus at C# 1.0 and just
not move any further. For those people that really want to be more
productive and want to build newer kinds of apps like SOA or whatever and
get into more dynamic styles of programming—adaptable programs and
more declarative styles of programming like we’re doing with LINQ—then
you’ve got to evolve or get out of the way, or something else will replace
you.

38. Entrevista
What do you suggest to become a better C# programmer?
It’s hard. There are many good books out there on C# programming and I
would encourage people to pick up one of the better books. I’m not going to
start naming names here, but there are many good books out there that will
help you become a better C# pro-grammer and help you better understand
the .NET Framework. There are many things available online that also help.
There are things like Codeplex. There’s a bunch of open source projects that
you can grab and look at and learn from and so forth.
To become a better programmer in general, one of the things that have
helped me is to look at different styles of programming and different kinds
of programming languages(…)

39. Entrevista
What’s facing us now and in five years?
Concurrency is the big one right now. That thing is right in our face, and we’ve got to
find solutions to that problem. One of my biggest challenges in the foreseeable future is
having our team work that issue.
Again, we’d like to do it in an evolutionary fashion, but how do you deal with the shared
state problem and side effects without breaking all the existing code? We don’t know
yet, but it very well may be that that concurrency is a big enough paradigm change that
whole new languages are needed or whole new frameworks are needed. Although I
don’t think we’re at that point yet. I think there’s a lot of ground that we can gain from
making it possible for people to write APIs that internally are massively parallel and
written by people that really understand a particular domain, be it transformations or
numeric processing or signal processing or bit- maps or image manipulation. (…)

40. Entrevista
Does the object-oriented paradigm create problems?
You know, it depends on what you group under the object-oriented paradigm.
Polymorphism and encapsulation and inheritance are as such not a problem,
although functional languages typically have a different view of how you do
polymorphism with their algebraic data types. Aside from that, I think the biggest
problem typically with object-oriented programming is that people do their object-
oriented programming in a very imperative manner where objects encapsulate
mutable state and you call methods or send messages to objects that cause them to
modify themselves unbeknownst to other people that are referencing these objects.
Now you end up with side effects that surprise you that you can’t analyze.
In that sense object-oriented programming is a problem, but you could do object-
oriented programming with immutable objects. Then you wouldn’t have these same
problems. That’s kind of what functional programming languages are doing, for
example.

41. Entrevista
Regarding your interest in functional programming, should
computer science students study more math and experiment
more with functional programming?
Well, I certainly think that it is important to include functional programming in
any computer science curricula. Whether you start with it that depends. I’m not sure that
your very first introduction to programming should be functional programming, but I
definitely think that it ought to be part of a curriculum.

42. Entrevista
What lessons should people learn from your experience?
Well, if you look at the first product I worked on, Turbo Pascal, it was very much
about not believing the traditional way of doing things. Don’t be afraid. Just because peo
ple tell you it can’t be done, that doesn’t necessarily mean that it can’t be done. It just
means that they can’t do it. I think it’s always fun to think outside of the box and try to
find new solutions to existing problems.
It was the only thing I wanted to do. I was very, very passionate about it.
You have to have that passion to get really good at something, because that makes you
put in the hours, and the hours are the real key. You need to put in a lot of work.