Which programming language you like the most and why?

[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

[Super Lloyd]

now, what is it about bacon!?

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.

[Michael Haines]

My favorite is the one that keeps me gainfully employed. I am currently working several projects at a time and working in C#, VB, Java, Groovy, Javascript, XUL, and a proprietary templating language for UIs. I finish lines of VB with semi-colons and forget the ()s on If statements in Java/Groovy/Javascript. If someone knows how to setup eclipse and VS to catch these mistakes, that would be a feature I'd like to have. You are here - through no fault of mine!

[RugbyLeague]

I agree. But haters gonna hate :)

[PIEBALDconsult]

To know her is to love her. I guess you don't know her like I do.

Rob Grainger wrote:

Joins. WTF is that fugly syntax.

Perhaps you're using Oracle?

Rob Grainger wrote:

DISTINCT (it should be implicit in every query)

Heck no. I very rarely use DISTINCT; I did the other day, first time in years, I was being lazy. About the worst thing I can say about SQL is that BETWEEN shouldn't be inclusive.