Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Static and primitives are not part of OOPs. I have read that static and primitives are not allowed in scala class definitions. If this is true, then why static and primitives were allowed in java and in c# and few other languages?
They are not part of "pure" Object Oriented, but sometimes "pure" gets in the way of "getting the job done".
Using primitives can make mathematical operations (in particular) much faster, and statics enable a lot of useful design patterns.
C#, C++ and Java are a general purpose programming languages. You can find for example elements of duck-typing in C# 4.0, elements of functional programming, and many more useful constructs.
Not every program and not every part of a program has to be object oriented. Use OOP when needed and when it serves purpose, in C#, C++ and Java you can use other or simpler constructs every time you feel OOP is a 'firing mosquito with a cannon'.
Its an engineering decision. Like most engineering decisions it involves carefully balancing lots of different forces on the design. In this case its the design of the language. Different languages are intended to solve different problems and have different objectives. So its not surprising that different languages come to different conclusions.
It this case there are costs and benefits to having primitives.
Primitives can be faster.
Primitives can make it easer to do certain low level things (eg writing individual bits to a register on a micro condoler in an embedded system.)
On the other hand primitives can make your programming language more complicated as your primitive types have different syntax etc to operate on them. Some newer languages are trying to have there cake and eat it by using primitive types under the covers but making them look like objects in terms of syntax.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have recently started working on a new DotNet Core project. I had noticed that someone (developer) used the Language-Ext library in this project. It was a new thing for me so I got to know that it is for Functional programming. It was quite confusing for me to understand it. I googled it and found benefits of it (Functional programming) :
Less Code (main point)
Easier Debugging
Easier testing
For a OO programmer, functional programming is quite different. So, my question is do we really need to use Language-Ext (functional programming) in C#? Are there any other benefits which I am missing?
So, my question is do we really need to use Language-Ext (functional programming) in C#?
If you want to do functional programming in C# you don't need LanguageExt, but IMO this is the best library for this use case.
Are there any other benefits which I am missing?
I'm biased because I use LanguageExt for some years now and it's my favourite library. If I create/edit C# projects without this library it feels a bit like working with an ancient C# version.
What more benefits are there?
Getting rid of (many1) bugs
Getting rid of much boiler plate code
Immutable data types
Avoiding side effects (easier parallel processing)
Easier refactoring
More type safety
Can be combined with non-FP C# code (use where useful)
Better refactoring skills (get another perspective)
LanguageExt creator Paul Louth created a great introduction showing some benefits:
https://github.com/louthy/language-ext
The library now has a lot more features and if you get into this (and functional programming at all) you will find many gems.
(On the premise that you want to stay with C# -- and not use F# or Haskell or ...)
"do we really need to use Language-Ext (functional programming) in C#?"
of course not; it looks like some people choose to do that; this is IMO a tiny minority of C# users. If you wanted to embrace functional style, you'd probably look at F# (while C# does offer some minor nods to functional programming, it isn't the speciality of the language). If language-ext adds just that bit more that you want... great? But this is entirely subjective and contextual.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm learning C# recently with a strong C++ background, and there is something about C# that I don't quite understand, given my understanding of and experiences with C++.
In C++, people do care a lot about uniformity, otherwise it would be impossible to write generic code using template meta-programming. In C#, however, people seem to care little about uniformity. For example, while array types have a Length property, List<T> uses Count. While IndexOf, LastIndexOf, and alike for array types are static methods, their counterparts for List<T> are not. This gives me the impression that instead of being uniform, C# is actually trying hard to be nonuniform. This doesn't make sense to me. Since C# doesn't support template meta-programming, uniformity is not that important as in C++. But still, being uniform can be beneficial in many other ways. For example, it would be easier for humans to learn and master. When things are highly uniform, you mater one, and you master it all. Please note that I'm not a C++ fanatics nor diehard. I just don't really understand.
You've got a conceptual issue here.
List<T>, and the other collection classes with it, aren't C# constructs. They are classes in the BCL. Essentially, you can use any BCL class in any .NET Language, not just C#. If you're asking why the BCL classes differ in certain ways, it's not because the designers disrespected or didn't want uniformity. It's probably for one of (at least two) reasons:
1) The BCL and FCL evolved over time. You're likely to see very significant differences in classes that were introduced before and after generics were added. One example, DataColumnCollection, is an IEnumerable (but not an IEnumerable<DataColumn>). That causes you to need to cast to perform some operations.
2) There's a subtle difference in the meaning of the method. .Length, I believe, is made to imply that there's a static number somewhere, where .Count implies that some operation might be done to get the number of items in the list.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
This article spells out some reasons F#'s performance is occasionally better than C#. It says in it's "Firstly" section that only F# generates tail calls.
What exactly does that mean? And why is it a performance boost? This one thing may actually make or break between F# and C# for my chess app, which uses a ton of recursion.
Performance will depend more on the way you implement your program than the language. F# may generate IL better for some things while the C# compiler will be better for others. When choosing the languages you should consider other things rather than just performance.
If you're writing your chess program to learn F#, give it a try, it's an awesome language, just don't expect super blazing fast programs just because you're using a functional language.
Edit to answer the new question:
The F# compiler indeed does generate IL that has the tail. op code whareas the C# compiler doesn't. That by itself doesn't make F# faster or more performatic than C#, as you can see in my original answer above, but can indeed make a difference in your specific chess app, since you are stating that recursion is heavily used.
As a side note, the CLR may generate some simpler tail call optimizations during runtime, so for simpler functions in a x64 enviroment, even IL generated by the C# compiler may have tail call optimization.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am engaged in a project that works mainly in AutoCAD to design and manufacture prefabricated building components such as roofing trusses. One of our goals is to redesign a program that was written in LISP that functions in designing roofing trusses. We are to rewrite the LISP code in C# and incrementally implement it into the current libraries that they have set up.
My problem is that I have been tasked with building a rudimentary LISP to C# converter. After some research (as Google results quickly show that such a thing does not readily exist on hand), I have come to the question of which way of converting this legacy code would be more efficient. Would it be better to take chunks of the LISP code to analyze and rewrite in C#, or should I continue on with developing a rudimentary converter for the AutoLISP code?
You should take chunks of the LISP code and rewrite in C#.
Even if it was less effort to write a general purpose LISP interpreter in C# than to rewrite the LISP in c# (which is highly improbable), the LISP is probably running AutoCAD commands like you would type in the AutoCAD command line instead doing things the ObjectARX way. So you would also need to convert the commands to use the ObjectARX API.
C# is a compiled object-oriented programming language whereas AutoLISP is an interpreted expression-oriented language. Therefore there is never going to be a really straightforward way of converting one to the other without a monumental effort.
Its worth noting that AutoLISP has flexibility to be modified quickly without needing to be recompiled. The benefit to using native in-process C# is that it's extremely fast versus a similar LISP approach. I've found there's a nice middle ground for maintaining the flexibility of LISP with the speed and power of C# which leverages the LispFunction command flag and ResultBuffer type in the .NET native API.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently start to learn C# and I want to know whether the C# is Pure Object-Oriented with reason in both the cases(cases yes or no).
I'm not %100 sure exactly the meaning of "pure" object-oriented but my answer is YES.
From Smaltalks wikipedia page;
Smalltalk is a "pure" object-oriented programming language, meaning
that, unlike Java and C++, there is no difference between values which
are objects and values which are primitive types. In Smalltalk,
primitive values such as integers, booleans and characters are also
objects,
That is the same as in C#.
I found an interesting article called Wyvern: A Simple, Typed, and Pure Object-Oriented Language
1.1 What Makes an Object-Oriented Model Pure?
From these sources, we extract three key requirements that we wish to
satisfy in coming up with a typed, pure object-oriented model:
Uniform access principle. Following Meyer, Cook, and Kay, it should be possible to access objects only by invoking their methods.
Interoperability and uniform treatment. Different implementations of the same object oriented interface should interoperate by default,
and it should be easy to treat them uniformly at run time (e.g., by
storing different implementations of the same interface within a
single run-time data structure).
State encapsulation. All mutable state should be encapsulated within objects.