Which programming language you like the most and why?

Pete OHanlon

That would be "I have a foot, and it's now full of holes"

Forgive your enemies - it messes with their heads

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Nagy Vilmos

Oh please no! Multiple inheritance opens such a large bag of pain. Interfaces give you that [to some degree] and I don't want any more.

Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

mla154

C# is my favorite. Here's why: http://www.codeproject.com/Members/mla154#_comments[^]

Regards, Mike

thrakazog

You don't have to use it if you don't like it. But .05% of the time it could come in handy. And I want it!

Kill some time, play my game Hop Cheops[^]

Lost User

Just a theory, but I would guess that then 99.99999999% of those times you would impliment and two months later say to yourself "ohhhhhh thats why that is not .Net compliant" ;) Just saying, it seems like it would be good up front (I thought the same when I realized I couldn't). But there is actually logical reasoning for it. Kind of like why things are base 0 index.

Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

Nagy Vilmos

I want a 24-hour live video link to Salma Hayek, but I can't have it.

Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

Steve Mayfield

I'd be really happy if I just get an inheritance from Bill G or Steve J :rolleyes:

Steve _________________ I C(++) therefore I am

Nemanja Trifunovic

OCaml - because it does not have nulls.

utf8-cpp

PIEBALDconsult

SQL. Because it's the best way to access and manipulate the data I need to access and mess with, and I can use it via a number of other (general-purpose) programming languages (C#, VB.net, C, etc.) as appropriate.

Gregory Gadow

LOLCode, because it makes me smile.

Rick York

That's a new language I am working on. Like many language names, it's actually an acronym : Binary Abstraction of Code and Other Notations

JimmyRopes

OriginalGriff wrote:

I'd like var removed except for Linq returns.

var in C# is not like var in some other languages. The var in C# is strongly typed based on what the type is of the object assigning to it. Quite a bit different than being loosely typed.

The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes

PIEBALDconsult

Nagy Vilmos wrote:

Interfaces give you that

The heck it does.

Nemanja Trifunovic

Nagy Vilmos wrote:

Multiple inheritance opens such a large bag of pain

Not at all.

utf8-cpp

OriginalGriff

I agree - which is why I see it's use and even necessity for Linq. But other than that, it is a sign of laziness, and of "I don't care what this is and I can't be bothered to work it out". Given Intellisense is pretty good, most of the time I have to type no more characters to get the actual type I am going to use than to get var. So which is easier to maintain? Strongly (but anonymously) typed variables, or the actual class name?

Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."

Rob Grainger

I see both points of view, but

SqlCommand command = new SqlCommand();

Seems a bit redundant. I prefer "var" there (especially for generic types). Most other times I use the type - it helps keep code readable. Maybe you should be arguing for coding standards where you work that codify these things (always a shame you need to tell people). Better still, stop employing sloppy programmers.

Rob Grainger

Nagy Vilmos wrote:

Multiple inheritance opens such a large bag of pain

I call you out there - C++'s implementation offers a whole bag of pain, but try it in SELF and you'll see that its an incredibly powerful technique. The main problem is that in statically typed languages, inheritance is often confused with typing. Dynamically typed languages don't have this problem, so you can freely mixin behaviour. I'd like to see a type-safe language with something more like duck-typing - allowing non-related classes to be polymorphic if they have the same interface (not a Java/COM-style interface, but real interface). i.e. two objects are polymorphic on the set of common methods they have, regardless of their relationship through inheritance. C#'s extension methods attempt to fill the same gap - adding features to existing classes (and interfaces), but do so only by compromising OO - these are all static methods, can't be overridden, etc.

Rob Grainger

Really, I've always thought SQL was a hardship we have to endure. To whit... 1. Dates. WTF?!!?? No real standard support for dates. 2. Joins. WTF is that fugly syntax. 3. Aggregattion and grouping. WTF. 4. Use of DISTINCT (it should be implicit in every query) There's plenty more, but it always struck me as a butt-ugly language, poorly designed for the task in hand. I mean honestly, a language for accessing relational databases that fails to be even relational: SQL Criticism[^]

BobJanova

Of the conventional languages, C# is excellent. One thing which is missing (related to the multiple inheritance thing) is a way of specifying that you implement an interface through a member field; this would simplify the provider based approach to multiple inheritance workarounds significantly. For example let's say we want to 'inherit'

class A {
void DoAStuff() {}
void DoStuff(int i) {}
}

class B {
int BStuff { get; set; }
void DoStuff(int i) {}
}

class C: A, B { ... }

This exposes a common problem in multiple inheritance, a 'common' method (what is C.DoStuff)? At the moment you can have interfaces IA and IB and have C implement both through member fields:

interface IA { void DoAStuff(); void DoStuff(int i); }
interface IB { int BStuff { get; set; } void DoStuff(int i); }

class A : IA {
void DoAStuff() {}
void DoStuff(int i) {}
}

class B : IB {
int BStuff { get; set; }
void DoStuff(int i) {}
}

class C: IA, IB {
A a; B b;

void IA.DoAStuff() { a.DoAStuff(); }
// ... etc
}

What I want is

class C: IA, IB {
A a implements IA = new A();
B b implements IB = new B();
}

Also, I want array operations, particularly arithmetic. Writing

for(int i = 0; i < a.length; i++) c[i] = (2 * a[i]) + b[i];

... is tedious and obfuscating. I should be able to write

c = (2 * a) + b;

Given a free choice, a modern APL like Dyalog's offering is still the best for getting complex problems solved quickly. APL has made significant strides towards the 'normal' world in the last 10-15 years and you can now write readable structured code, use OO and talk to external components in a sensible fashion, but it still has all that crazy power if you need it. Something like R would also be good if I knew it as well as I do APL, probably.

RogelioP EX DE HL

nikunjbhatt84 wrote:

Which programming language you like the most and why? What feature(s) you love the most?

BASIC, because it allows me to Briskly Achieve Solutions Impossible in C For the meaty part of my "developer" life it has been usually the defined in IEC_61131-3 [^] - these are the ones I actually got paid to do. Been a while. For fun personal stuff C++ is somewhere in there. And Pascal... Logo... Forth... :-\ -- RP