The Daily WTF: Curious Perversions in Information Technology

ammoQ · 2005-11-23 Reply Admin

Kukster:

In any programmer's mind A = B; should not have any side effects beyond the value of A. It allows you, when debugging, to simplify things in your mind. Looking for a stack problem? X should not be suspect, F() is.

This is only true for C-like languages. Other langages (e.g. Pascal, ADA, PL/SQL) allow functions without parameters to be called without parenthesis.

ammoQ · 2005-11-23 Reply Admin

christoofar:
ehabkost:
christoofar:
ammoQ:

public Foo Bar { set { try { process(value); moreProcess(value); evenMoreProcess(value); } catch { Bar = value.playSafe; // Recursion } } }

That gets close to violating the principle of least surprise. What do I mean by that? You usually don't expect an exception to be raised when you read a property... maybe when you set one, but not when just reading it.

Uh... did you read the code above? Where would the code above raise an exception on get?

Yes, I did. I didn't say it generated an exception, it's going to be a SURPRISE when you theoretically run it and it locks up your process. Get it, principle of least surprise?

The idea of my example is that "value.playSafe" returns a "safe" version of value that doesn't cause an exception.
For example, let's assume value is some kind of unicode string and some of the processing might trigger an exception because the string contains characters not in the ISO8859P1 encoding; so the "playSafe" method would replace or remove all "evil" characters from the string.

2005-11-23 Reply Admin

isnt the pound symbol £ ?

2005-11-23 Reply Admin

christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

Actually, you shouldn't raelly previx your C++ member variables with just an underscore. The use of underscore prefixing is "reserved for implementation" :)

Just thought i'd mention it :) Sorry if someone has already pointed this out.

OJ

bullestock · 2005-11-23 Reply Admin

Anonymous:
christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.
Identifiers with a leading underscore are resevered for the compiler in C++. You don't do that.

Wrong. Identifiers starting with a leading underscore followed by an uppercase letter are reserved for the compiler. Additionally, identifiers containing two consecutive underscores are reserved.

So, XX_XX, _xxx, _xXX are all legal, while _X, __x, and XX__XX are reserved.

bullestock · 2005-11-23 Reply Admin

procyon112:

One underscore followed by any alphanumeric character is also reserved for library writers (which brings up an interesting point that all variables starting with an underscore are illegal except the variable single-underscore '_')

Not true. See my other post.

bullestock · 2005-11-23 Reply Admin

No I mean one underscore. Read the C++ standard [17.4.3.1.12]: "Each name, that begins with an underscore is reserved to the implementation for use in the global namespace".

The key phrase here is "the global namespace". In plain English, this means that you are not allowed to create a global function or global variable with a name beginning with '_'.

Member variables and member functions do not suffer from this limitation, however.

2005-11-23 Reply Admin

Or could it be Delphi? since the architect behind C# was the architect behind Delphi...

LOL

bullestock · 2005-11-23 Reply Admin

Kukester:
In any programmer's mind A = B; should not have any side effects beyond the value of A. It allows you, when debugging, to simplify things in your mind. Looking for a stack problem? X should not be suspect, F() is.

Guess you don't like classes then.

brazzy · 2005-11-23 Reply Admin

Cyresse:
Anonymous:

lol, this is such a newb.

I've been codin in C# for like 10 yrs and never done such dumbass thing lol. [H] net really sux cause it has so many bugs. Sun should have fixed them all already, I found them. rofl. This would never happen in ruby cause it's not that dumb. Googd languages dont' allow you to do dumb thingies. I don't like c# anymoore because of this crap.

*cough* Troll. *cough*

It's an indication of the sad state of this forum that it would be considered trolling rather than enormously funny.

brazzy · 2005-11-23 Reply Admin

sao:
And who do you think you are, we ALL know its C-HASH. # == HASH. i like hash.

Bah. For me, it's C-Dingsda or, in English, C-Thingamabob.

2005-11-23 Reply Admin

Anonymous:
>
rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign).

Well, If "preprocessor" did what you say it should, than in this particular case the preprocessor itself would die with "stack overflow" error.

Taladar · 2005-11-23 Reply Admin

I think the real WTF here is "Why did they add syntactic sugar for getters and setters but none for default getters/setters (like Ruby)?"

larsrc · 2005-11-23 Reply Admin

Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.
[...]

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

I tend to agree here, but of course that is a language design decision. I have changed from liking to disliking operator overloading, especially of the very basic operators like '='. While abstracting out complexity, hiding it so utterly that you can't tell how long basic operations will take (constant, O(n^K), infinite recursion) is an invitation for subtle bugs and misdesigns. IMHO, '=' should assign the value and nothing else, if you want to do fancy things in the setters and getters, use proper methods so recursion like this is visible.

A similar thing happened to me in C++, though:) I casted one object O1 to another class, getting O2, and (being an old C-coder) expected O1 == O2 to be true. Didn't notice that O2 had a constructor taking O1, so the cast created a new object instead of just giving a new type to the original object. Took me forever to figure out that casting was magical in C++.

I'd say C++ is much worse than C# on this, as it allows even more operator overloading, What I'm trying to say, I guess, is that C++ isn't an even remotely thought-out language.

-Lars

trollable · 2005-11-23 Reply Admin

Nothing new here. We have the same problem with Eiffel, Delphi, ... This is the uniform call for methods without parameters. The advantage is the ability to improve the code without breaking the modules that depend on it. The drawback is clearly shown in the OP. So

is Properties a good thing?
is Public Fields a good thing?
is Uniform Call a good thing?

Widely discussed already. IMHO, no, no and no. But others differ.

CornedBee · 2005-11-23 Reply Admin

christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

It's also an invalid coding style in C++, because the standard reserves all identifiers that start with an underscore for internal compiler use, e.g. the implementation details of the standard library.

But the coder is right. It wouldn't have happened in C++, because C++ doesn't have properties. The lengths you have to go to to successfully emulate them (it's largely possible, with one exception) just aren't worth it for most, as the resulting syntax is horrible.

Or in Java: Sun makes the correct claim that there are no function calls in Java not explicitely recognizable as such, with the exception of GC stuff (finalizers etc.). Thus you can't have a recursive call where there's no obvious call.

ammoQ · 2005-11-23 Reply Admin

trollable:
Nothing new here. We have the same problem with Eiffel, Delphi, ... This is the uniform call for methods without parameters. The advantage is the ability to improve the code without breaking the modules that depend on it. The drawback is clearly shown in the OP. So

is Properties a good thing?

is Public Fields a good thing?

is Uniform Call a good thing?

Widely discussed already. IMHO, no, no and no. But others differ.

I think this is mostly a semantical problem, independend from the syntax of the particular language.
Does anyone expect a getter or setter in Java to be dangerous anymore, given the legions of IDE-generated most simple getters and setters?

2005-11-23 Reply Admin

Wouldn't this have been neater as:

public class User
{
  protected string lastName = "";
  public string LastName
  {
    get 
    {
        return lastName;
    }
    set 
    {
        lastName = <FONT color=#0000ff>value</FONT>;
    }
  }
}

Personally I'd take C# over C++ or C any day of the week. I have always found C++ quite <<UGLY* - to> read.

I frequently use a mixture of the following formats (per project basis):

<FONT style="BACKGROUND-COLOR: #ffffff" color=#008000>m_PrivateVar</FONT>,

<FONT color=#008000>_PrivateVar</FONT>, and

```
privateVar.
```

Normally together with the <FONT color=#008000>PublicVar</FONT>.

I guess which style you use, depends on the project you are working on.

Normally the project senior developer has defined their preferred naming convention and it is good practice to maintain consistency.

Ben

P.S. Does the CAPTCHA always fail the first time, or is it just me?

rsynnott · 2005-11-23 Reply Admin

mrsticks1982:

yes, it is a c with the pound symbol but it is C-SHARP .... <cue>charlie brown scream as he tries to kick the american football</cue>

Hmm, I once came across someone who got upset when people didn't call C# "C Sharp" (it's clearly C-Octothorpe), but who also insisted on calling SQL "Sequel". Interesting.

2005-11-23 Reply Admin

This code is fucking stupid in itself, Somebody just wrote that 9 lines of error prone code since wanted to attach a None -> "" behavior to one string?!? i don't think it is the idea in high level languages to write many lines of shit, not even in c#...

I'd leaved that 'feature' out since it is not the way to go with strings. rather set the string in initialisation and go out with one liner.

i wonder how there can be best coder who uses C++ but refuses to try high level languages because he's ignorant religious fool.

___
LISP rulzz.

2005-11-23 Reply Admin

Great Britain does NOT use the €, they still have the £.

2005-11-23 Reply Admin

larsrc:

A similar thing happened to me in C++, though:) I casted one object O1 to another class, getting O2, and (being an old C-coder) expected O1 == O2 to be true. Didn't notice that O2 had a constructor taking O1, so the cast created a new object instead of just giving a new type to the original object. Took me forever to figure out that casting was magical in C++.
-Lars

My guess is that you fail to use the C++ way of casting, that is static_cast, reinterpret_cast, dynamic_cast or const_cast. C-style casts are deprecated, and to be honest even when using them this behavior shouldn't occur. What I expect is that you casted "by value" so then the compiler did exactly what you wanted.

masklinn · 2005-11-23 Reply Admin

trollable:

is Properties a good thing?

is Public Fields a good thing?

is Uniform Call a good thing?

Yes, yes and yes. The ability for idiots to break everything using these features shouldn't prevent "good" programmers from having them available. Just stick the idiots to languages that don't allow them to be idiotic (ADA or Java).

Rank Amateur · 2005-11-23 Reply Admin

No, "this crap would never happen in C++." Instead of recursion, you'd get a function reassigned to god-knows-what pointer.

class User
{
protected:
String lastName;
//etc.
public:
// One function for getting *and* setting lastName. Aren't I clever?
String LastName(String value = NULL)
{if (value != NULL) LastName = value; return lastName;};
//etc.
};

And I ought to know. Once it took me 2 hours to find a bug, and it turned out I had... uh.... Never mind.

--RA

2005-11-23 Reply Admin

Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

I'm sorry, but you're a moron (are you this "self-proclaimed best coder in the world"?). There is no declared member variable called "LastName", only one called "lastName", so how exactly would the compiler figure out the assignment? Would this work in C++? I don't think so, unless you'd switched off case-sensitivity on the compiler. But you wouldn't do that.... would you? What you'd get is a compile-time error rather than a runtime error. However, if you actually bothered to read the compiler warnings you'd also see something like "Field 'User.lastName" is never assigned to, and will always have its default value null". You could also tell the compiler to treat warnings as errors, which would get you back your nice compile-time error... but of course then you'd have to take a bit more care when writing your code to start off with, so maybe you wouldn't like that. And for goodness sake learn to read. If you (and he) actually learned to code properly in the language you're working with you wouldn't have a problem anyway.

TechNoFear · 2005-11-23 Reply Admin

Anonymous:
Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

I'm sorry, but you're a moron (are you this "self-proclaimed best coder in the world"?). There is no declared member variable called "LastName", only one called "lastName", so how exactly would the compiler figure out the assignment? Would this work in C++? I don't think so, unless you'd switched off case-sensitivity on the compiler. But you wouldn't do that.... would you? What you'd get is a compile-time error rather than a runtime error. However, if you actually bothered to read the compiler warnings you'd also see something like "Field 'User.lastName" is never assigned to, and will always have its default value null". You could also tell the compiler to treat warnings as errors, which would get you back your nice compile-time error... but of course then you'd have to take a bit more care when writing your code to start off with, so maybe you wouldn't like that. And for goodness sake learn to read. If you (and he) actually learned to code properly in the language you're working with you wouldn't have a problem anyway.

is this what they call "unformatted code" ?

trollable · 2005-11-23 Reply Admin

masklinn:
trollable:

is Properties a good thing?

is Public Fields a good thing?

is Uniform Call a good thing?

Yes, yes and yes. The ability for idiots to break everything using these features shouldn't prevent "good" programmers from having them available. Just stick the idiots to languages that don't allow them to be idiotic (ADA or Java).

Which language do you use? ADA or Java?

More seriously, the question is: Are properties, public fields and uniform call a good thing for good programmers? IMHO, all the three are anti-OOP.

trollable · 2005-11-23 Reply Admin

ammoQ:
I think this is mostly a semantical problem, independend from the syntax of the particular language.

Yes, this is a semantic problem and IMHO, a very important one. But the syntax has a role, especialy for the Uniform Call.

ammoQ:
Does anyone expect a getter or setter in Java to be dangerous anymore, given the legions of IDE-generated most simple getters and setters?

I do, espcialy for setters. At the minimum, I expect the method to at least fire some events (probably in the same threads). But this is not a problem because a setter is clearly a method so it is expected. OTOH, with the Uniform Call, you don't know if you're just setting a value or calling some code. Bad.

ammoQ · 2005-11-23 Reply Admin

masklinn:
trollable:

is Properties a good thing?

is Public Fields a good thing?

is Uniform Call a good thing?

Yes, yes and yes. The ability for idiots to break everything using these features shouldn't prevent "good" programmers from having them available. Just stick the idiots to languages that don't allow them to be idiotic (ADA or Java).

A well-educated idiot can break every language, even Logo.

brazzy · 2005-11-23 Reply Admin

masklinn:
trollable:

is Properties a good thing?

is Public Fields a good thing?

is Uniform Call a good thing?

Yes, yes and yes. The ability for idiots to break everything using these features shouldn't prevent "good" programmers from having them available. Just stick the idiots to languages that don't allow them to be idiotic (ADA or Java).

There is no language that doesn't allow you to be idiotic. There are just those that try to make it difficult (though of course to a truly gifted idiot, that's merely a challenge), and those that all but encourage it.

And of course there's always the problem that the good programmer ends up having to maintain the idiot programmers' code and wishing the project had used a less feature-rich language after all...

ammoQ · 2005-11-23 Reply Admin

brazzy:
masklinn:
trollable:

is Properties a good thing?

is Public Fields a good thing?

is Uniform Call a good thing?

Yes, yes and yes. The ability for idiots to break everything using these features shouldn't prevent "good" programmers from having them available. Just stick the idiots to languages that don't allow them to be idiotic (ADA or Java).

There is no language that doesn't allow you to be idiotic. There are just those that try to make it difficult (though of course to a truly gifted idiot, that's merely a challenge), and those that all but encourage it.

And of course there's always the problem that the good programmer ends up having to maintain the idiot programmers' code and wishing the project had used a less feature-rich language after all...

Those languages that encourage idiocy are what I call "write only" languages, since it's pretty hard (even for an experienced coder) to read programs using many or all features in that languages.

2005-11-23 Reply Admin

WTFer:
BlackTigerX:
I bet more than half the readers didn't catch the problem with the code

Yes, I have been programming in C# for 3 years and I still make that mistake once in a while. The problem isn't doing that mistake. The problem is thinking you are the best coder in the world and thinking that the problem is the language and not you, considering that this is a bug easy to find.

100% agree. I'm far from the best coder even at my company, however different languages have different syntax/work in different ways. If one doesn't work like the other, part of your job is to know where these differences lie. Not to say "well if this worked like this..." That doesn't get you anywhere.

Kind of like arguing with your girlfriend.

RevMike · 2005-11-23 Reply Admin

ammoQ:
brazzy:
masklinn:
Just stick the idiots to languages that don't allow them to be idiotic (ADA or Java).

There is no language that doesn't allow you to be idiotic. There are just those that try to make it difficult (though of course to a truly gifted idiot, that's merely a challenge), and those that all but encourage it.

And of course there's always the problem that the good programmer ends up having to maintain the idiot programmers' code and wishing the project had used a less feature-rich language after all...

Those languages that encourage idiocy are what I call "write only" languages, since it's pretty hard (even for an experienced coder) to read programs using many or all features in that languages.

Perl is the classic example. The terse constructs and global variables that may be ok within a 25 line "shell script" become a major headache in a full sized application.

I often wonder what large systems built in Perl must look like. I understand that some major web companies like Amazon run their systems on Perl. I would guess that in order to run a successful enterprise on Perl they need to be especially careful about defining and enforcing sensible code standards.

This is not a knock on Perl. Perl remains to this day my favorite language, although I generally use it as a swiss army knife for quick jobs not as a full development environment.

hank miller · 2005-11-23 Reply Admin

bullestock:
Anonymous:
christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.
Identifiers with a leading underscore are resevered for the compiler in C++. You don't do that.

Wrong. Identifiers starting with a leading underscore followed by an uppercase letter are reserved for the compiler. Additionally, identifiers containing two consecutive underscores are reserved.

So, XX_XX, _xxx, _xXX are all legal, while _X, __x, and XX__XX are reserved.

Careful now. I once pointed this out to our (former) chief programmer, and nearly got fired for questioning his code. It worked on his system, where the compiler wasn't fussy about using all the reserved identifiers. Didn't work on mine with a different compiler that treated reserved identified differently.

hank miller · 2005-11-23 Reply Admin

RevMike:

Perl is the classic example. The terse constructs and global variables that may be ok within a 25 line "shell script" become a major headache in a full sized application.

I often wonder what large systems built in Perl must look like. I understand that some major web companies like Amazon run their systems on Perl. I would guess that in order to run a successful enterprise on Perl they need to be especially careful about defining and enforcing sensible code standards.

This is not a knock on Perl. Perl remains to this day my favorite language, although I generally use it as a swiss army knife for quick jobs not as a full development environment.

In my experience large applications written in perl tend to go years between upgrades (even bug fixes), because nobody can figure out how to safely modify anything.

You can write good code in perl. The language doesn't encourage it though.

I use python for most of my small-medium stuff (even though for the really small stuff perl would be faster). Python encourages good code, but I still have many examples of bad code - I'm working on a few submissions.

2005-11-23 Reply Admin

I'm pretty sure the correct pronunciation is "C octothorpe".

2005-11-23 Reply Admin

christoofar:

Because Americans and Canadians in the early days reserved the £ to mean the "pound sign" or "number sign". Perfectly fine to have two meanings for something between countries. Happens in Spanish and Portuguese all the time (even sex tenses on verbs!)

What's a sex tense on a verb?

IIRC gender in spanish applies to nouns, not verbs, in which case it's not a tense.

But a sex tense would be an interesting tense. I'll leave its meaning as an exercise to the reader.

2005-11-23 Reply Admin

Anonymous:
christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

The funny thing is the code conforms to Microsoft's design guidelines for naming classes/members/properties (which I personally find to be quite lame):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

Those only apply to externally visible members. They don't contain anything specifically about naming private fields or methods.

I personally hate the _ convention for a number of reasons. 1. It's ugly. 2. It's an extra letter I have to type for Intellisense to work. 3. Identifiers starting with _ and __ are reserved in the C/C++ standards so I habitually don't use them. I find the upper/lower case convention easy enough to deal with. Espcially since I always use "this." for class members (to differentiate them from local variables) and both LastName and lastName will show up right next to each other in Intellisense, making it quite obvious that I need to pay attention to which one I use.

--Mike

Xepol · 2005-11-23 Reply Admin

Amazing. Three pages of signature stealing, human language arguements, and occasional code bastardization, and only ONE person who noted that the "expert's" assertion that this would never happen in C++ was bullshit, since it is almost identical to the same C++ code, which would EASILY allow you to do the same. Now, I do not condone bashing amateurs, but self proclaimed experts saying unbelievably stupid things? Ya, they are viable targets.

Take properties, add in case insenitivity and inevititably you get dumb shit like this. We all do it now and then, and there is nothing too bad about that, however making bad excuses that can't even stand up to minor scrutiny, there in lies the problem. Sure, bitch about the language if you want, but don't blame it for yer screwups.

To the person who noted that this would NEVER happen in VB.NET, almost true as it is case-insensitive unless you WANT it to be case sensitive, then this would STILL happen.

And yes, recursion can be a good thing in property setters if done properly.

Would a straight setting/getter work better with the string preassigned as someone suggested earlier? No. Assigning a null to the setter would then mean the getter could get the null back. The getter code covered all instances of returning nulls transparently, and besides, the problem was actually in the setter anyways, so why they hell would you fix the part that wasn't broken?

Ultimately, for me the WTF is why people keep perpetuating case-sensitive languages. You've been taught all your life that A and a are the same symbol. It is natural for you to think that way. Computers are designed the opposite way. Yes, you can retrain yourself so that 99% of the time you think the way the computer does, but that other 1% puts you in opposition to the computer, which NEVER makes that mistake. It would just be easier for languages to be case-insensitive. Rather than trying to force our minds to work like the computer, it would be better for the computer to work like us.

Yes, that would start a language war... I'm saying any language is better than another because of the case (in)sensitivity issues, but rather it fights our natural way of thinking leading to inevitable mistakes. I favour the computer doing the heavy lifting everytime - hell, if I wanted to do everything the hardway, I would still code in assembler.

Xepol · 2005-11-23 Reply Admin

And once the whole case issue is behind us, we could move on to other, really dumb problems instead [:D]

2005-11-23 Reply Admin

One of the most massive benefits of the .net languages, which sets them far apart of java or other languages, is exactly the ability you call stupid.... real, native, properties.

Just becuase no one was able to implement it properly in the past, doesn't make it bad. It's actually quite practical, given that OO programming is based entirely around properties, shouldn't we have them?

Xepol · 2005-11-23 Reply Admin

And once the whole case issue is behind us, we could move on to other, really dumb problems instead!

diGriz · 2005-11-23 Reply Admin

Well, this programming oops can happen easily, because the IntelliSense of the VisualStudio sometimes offers the wrong element. So much for "how can this happen". But even beginners can find this error, especially with debugging.

So if this self proclaimed super hero of the code is unable to find the source of the problem, Jon should use s/best coder/biggest loser/ on him.

RevMike · 2005-11-23 Reply Admin

Anonymous:
One of the most massive benefits of the .net languages, which sets them far apart of java or other languages, is exactly the ability you call stupid.... real, native, properties.

Just becuase no one was able to implement it properly in the past, doesn't make it bad. It's actually quite practical, given that OO programming is based entirely around properties, shouldn't we have them?

Yeah. I want the ability to set the visibility of a property differently for read and write operations. I should be able to make a value public read but private (or protected, or package) write. Then I won't need all those silly getters but still can protect the change of a value with a method call.

Anonymoose · 2005-11-23 Reply Admin

The world's best coder is not someone who uses one language as a crutch, no, the world's best coder knows ALL programming languages inside and out, and can make them all do backflips.
This includes, of course, being able to write in high level languages, right down to programming using switches to enter machine codes on a variety of hardware.
Wonder if anyone's come up with a binary programmer for a JVM? Ha!

Hmm, maybe contender for world's greatest airbag.

RevMike · 2005-11-23 Reply Admin

Anonymoose:
The world's best coder is not someone who uses one language as a crutch, no, the world's best coder knows ALL programming languages inside and out, and can make them all do backflips.
This includes, of course, being able to write in high level languages, right down to programming using switches to enter machine codes on a variety of hardware.
Wonder if anyone's come up with a binary programmer for a JVM? Ha!

Hmm, maybe contender for world's greatest airbag.

There are several Java Assemblers. Here is one: http://tinf2.vub.ac.be/~dvermeir/courses/compilers/javaa/

2005-11-23 Reply Admin

brazzy:
sao:
And who do you think you are, we ALL know its C-HASH. # == HASH. i like hash.

Bah. For me, it's C-Dingsda or, in English, C-Thingamabob.

Let's call it C-XXO. ^_^

masklinn · 2005-11-23 Reply Admin

Anonymous:
One of the most massive benefits of the .net languages, which sets them far apart of java or other languages, is exactly the ability you call stupid.... real, native, properties.

Just becuase no one was able to implement it properly in the past, doesn't make it bad. It's actually quite practical, given that OO programming is based entirely around properties, shouldn't we have them?

WTF, C#'s properties are one of the most useless implementations of these.

(and you should check Ruby's implementation and usage of properties to see what a proper implementation of properties and a language built upon them looks like)

Raven · 2005-11-23 Reply Admin

Well.. I'm no C++ expert but he might be right about this thing would never happen in C++.
What compiler would (or should) accept something like:

somefunction() = variable;

Maurits · 2005-11-23 Reply Admin

Raven:
Well.. I'm no C++ expert but he might be right about this thing would never happen in C++.
What compiler would (or should) accept something like:
somefunction() = variable;

See "Using a Function Call as an Lvalue"
http://www.devx.com/tips/Tip/29288?trk=DXRSS_recentTips

Buggy.NET

Leave a comment on “Buggy.NET”