• (cs) in reply to ammoQ
    ammoQ:
    John Smallberries:

    Does anyone care to comment on whether or not the VB compiler is doing the right thing? Does anyone still use VB? Does anyone care?


    Considering the nature of structs, a struct without non-static fields has a size of 0 bytes. I wonder how C# allocates an instance of such a struct.

    In .Net, structs are value types (as opposed to reference types) and so are usually stack allocated. Now, a struct that has no instance members will never be instantiated, per se. This particular struct would have pointers its string members (strings are reference types, so the data is on the heap), so it wouldn't be zero bytes. Where exactly this would be allocated, I'm not sure; I would guess in a region on the heap set aside for class (not object) data for the appdomain.

    Anyone know more about the esoterica of .Net memory allocation?
  • (cs) in reply to John Smallberries
    John Smallberries:
    ammoQ:
    John Smallberries:

    Does anyone care to comment on whether or not the VB compiler is doing the right thing? Does anyone still use VB? Does anyone care?


    Considering the nature of structs, a struct without non-static fields has a size of 0 bytes. I wonder how C# allocates an instance of such a struct.

    In .Net, structs are value types (as opposed to reference types) and so are usually stack allocated. Now, a struct that has no instance members will never be instantiated, per se. This particular struct would have pointers its string members (strings are reference types, so the data is on the heap), so it wouldn't be zero bytes. Where exactly this would be allocated, I'm not sure; I would guess in a region on the heap set aside for class (not object) data for the appdomain.

    Anyone know more about the esoterica of .Net memory allocation?


    I tried the following with the C# compiler of portable.net; it compiles and doesn't crash ("nix" means "nothing" in German):

    using System;

    public struct nix {
            public static int x;
    }

    public class test {
      public static void Main(string[] args) {
              nix a = new nix();
      }
    }

    So although it makes little sense, it's possible to instantiate the purely static struct.

  • (cs) in reply to John Smallberries
    John Smallberries:
    JohnO:

    John Smallberries:
    Interesting. It's silly (possibly dangerous) to do this, but I see no reason the compiler should reject it. In fact, the C# compiler has no problem with it.


    I do think the compiler is doing the right thing.  But that may be because I still think of structs in a C like way and I have yet to use on in c#.


    ipso facto, you think the C# compiler is doing the wrong thing? Or are the semantics of this construct different in the 2 languages?

    Not necessarily.  You could argue that VB.Net is overly verbose and is intended for the less gifted so a warning like this makes sense, since they probably don't understand scoping and are probably doing the wrong thing.  Whereas in c#, you could safely assume that they are doing what they intended to do.

    Seriously, I think it should warn in both languages.

  • (cs) in reply to wk633

    wk633:

    Ya, we once had a PC that kept flaking out with memory parity errors.  So our WTF went to fix it, and reported back that it was fixed.  After that it just crashed, with no error.  So our non-WTF guy went to check it, and found that WTF guy had turned off memory parity checking in CMOS.

    Reminds me of a job I once had where the company's core product was a web app that consisted of frames within frames within frames within frames. To access some JavaScript methods, you often saw code like window.top.opener.top.parent.opener.top.opener.parent.self.doStuff();

    As you might except, the app constantly had random JavaScript errors that no one could ever fix or even reproduce. Guess what the team's solution was? Yep, turn off JavaScript error messages in IE. I think they even put that into the installation guide they gave to customers.

     

  • (cs) in reply to A Wizard A True Star

    On the UserID thing, maybe the string actually has the username and the int has a numeric id?  Perhaps they should only use one identifier, but I could maybe imagine situations where that wouldn't be as good.  More likely, they should rename one of the variables to distinguish them.

  • (cs) in reply to ammoQ
    ammoQ:
    [

    So although it makes little sense, it's possible to instantiate the purely static struct.


    Not really. Under the hood, the compiler is adding a default public ctor. Try explicitly adding a private default ctor, and you should not be able to instantiate it.
  • Jonathan Bastien-Filiatrault (unregistered)

    Well, at school, using Visceral Studio 6, sometimes our program would crash with a runtime error unless we initialized a float variable to 0. So one would do:

    int main(int argc, char *argv[]) {
        float bleh = 0;

        ...usual
    }

    I almost failed an exam because of this.

  • (cs) in reply to John Smallberries
    John Smallberries:
    ammoQ:
    [

    So although it makes little sense, it's possible to instantiate the purely static struct.


    Not really. Under the hood, the compiler is adding a default public ctor. Try explicitly adding a private default ctor, and you should not be able to instantiate it.

    I wonder if a C# struct has some kind of "self awareness" like a class (carries type information with it) or if it leaves that to the compiler (like a C struct). Since there is no polymorphism with structs, the second option seems possible to me... or do I overlook something?
  • (cs) in reply to ammoQ
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    Speak German?

  • (cs) in reply to Jonathan Bastien-Filiatrault
    Anonymous:
    Well, at school, using Visceral Studio 6, sometimes our program would crash with a runtime error unless we initialized a float variable to 0. So one would do:

    int main(int argc, char *argv[]) {
        float bleh = 0;

        ...usual
    }

    I almost failed an exam because of this.


    That's probaby because not every possible combination of 32 bits is a valid float value.
  • (cs) in reply to Omnifarious
    Omnifarious:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    Speak German?



    Yes, I'm an Austrian. In that case, I was unsure whether to write "it" or "this", so I somehow mixed it ;-)
  • beest (unregistered) in reply to Anonymous Coward
    Anonymous:
    pjsson:
    LuciferSam:

    Maybe it was the way it was taught to me, but OO design didn't seem that hard.  I know people who graduated in my class that didn't know the difference between a class an object and a program.  That frightens me.



    According to OO design everything is an object, including program and classes (often called meta objects). Maybe it was you who didn't get it...


    Just because X is a Y does not mean that there is no difference between X and Y.




    Thanks for pointing that out. Concrete example of the logic being used in above argument:

    A Corvette is a car.
    A Pinto is a car.
    Both Corvettes and Pintos are cars.
    There is no difference between Corvettes and Pintos.
    QED
  • (cs) in reply to beest

    Maybe I should clarify my earlier statement about my classmates not understanding the difference between classes and objects.

    My classmate thought that classes and objects were identical and interchangable.  That once a class is defined, that an object of that class came into existance.  That there could only ever be one instance of a particular class.  Thus in his code there were Class1 - Class9 all identical when he needed/wanted 9 instances of Class.  Does this make sense?

    I refuse the expand on this further, it hurts my brain meats.

  • (cs) in reply to ammoQ
    ammoQ:
    Anonymous:
    Well, at school, using Visceral Studio 6, sometimes our program would crash with a runtime error unless we initialized a float variable to 0. So one would do:

    int main(int argc, char *argv[]) {
        float bleh = 0;

        ...usual
    }

    I almost failed an exam because of this.


    That's probaby because not every possible combination of 32 bits is a valid float value.


    Which ones?

    The above was a problem with, IIRC, Borland's C compiler.  printf() needs access to the FP library, because it handles FP.  If your program did not use any floats, the library would not be linked in.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to LuciferSam
    LuciferSam:
    Maybe I should clarify my earlier statement about my classmates not understanding the difference between classes and objects.

    My classmate thought that classes and objects were identical and interchangable.  That once a class is defined, that an object of that class came into existance.  That there could only ever be one instance of a particular class.  Thus in his code there were Class1 - Class9 all identical when he needed/wanted 9 instances of Class.  Does this make sense?


    Yes.  What he did follows from his misunderstanding.  That particular misunderstanding is, IME, common.  I have not come up with a way of clearly distinguishing the two for them as I do not understand why they do not understand.

    Due to an unclearly written bit of manual, I had a misunderstanding about inherited member variables when I was first learning OOP.  I still have code based on this misunderstanding in the system I wrote.  (The code works.  It just could be written better.  Hey, I learn.)

    I refuse the expand on this further, it hurts my brain meats.


    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    ammoQ:
    Anonymous:
    Well, at school, using Visceral Studio 6, sometimes our program would crash with a runtime error unless we initialized a float variable to 0. So one would do:

    int main(int argc, char *argv[]) {
        float bleh = 0;

        ...usual
    }

    I almost failed an exam because of this.


    That's probaby because not every possible combination of 32 bits is a valid float value.


    Which ones?

    I'm only guessing. Maybe the compiler/libs/etc. had a special expectation which of the 2^23-1 possible representations of NaN are acceptable. Maybe it didn't like denormalized numbers.


    The above was a problem with, IIRC, Borland's C compiler.  printf() needs access to the FP library, because it handles FP.  If your program did not use any floats, the library would not be linked in.



    Why would the program crash then?
  • What the fag (unregistered) in reply to LuciferSam
    LuciferSam:

    That is that many people don't seem to understand the where classes or structures should be static or not.


    And does your code make as much sense as your grammar?

  • itsme (unregistered)

    I don't get it.

  • (cs) in reply to JohnO
    JohnO:
    John Smallberries:
    JohnO:

    John Smallberries:
    Interesting. It's silly (possibly dangerous) to do this, but I see no reason the compiler should reject it. In fact, the C# compiler has no problem with it.


    I do think the compiler is doing the right thing.  But that may be because I still think of structs in a C like way and I have yet to use on in c#.


    ipso facto, you think the C# compiler is doing the wrong thing? Or are the semantics of this construct different in the 2 languages?

    Not necessarily.  You could argue that VB.Net is overly verbose and is intended for the less gifted so a warning like this makes sense, since they probably don't understand scoping and are probably doing the wrong thing.  Whereas in c#, you could safely assume that they are doing what they intended to do.

    Seriously, I think it should warn in both languages.


    The compiler doesn't just issue a warning, it fails to compile:

    Structure 'UserInformation' must contain at least one instance member variable or Event declaration.

    Even if it was a warning, I don't think I agree with you. There should already be warnings about unreferenced variables (there are in C#,  but not in VB).
  • (cs) in reply to ammoQ
    ammoQ:
    John Smallberries:
    ammoQ:
    [

    So although it makes little sense, it's possible to instantiate the purely static struct.


    Not really. Under the hood, the compiler is adding a default public ctor. Try explicitly adding a private default ctor, and you should not be able to instantiate it.

    I wonder if a C# struct has some kind of "self awareness" like a class (carries type information with it) or if it leaves that to the compiler (like a C struct). Since there is no polymorphism with structs, the second option seems possible to me... or do I overlook something?

    They do carry type information. You can reflect over structs just like anything else in .Net.

    In speaking to a friend of mine (thanks, Chris), he thinks that a .Net struct with all static members will simply have the int type descriptor and so would take up 4 bytes. The static members are simply scoped globals on the appdomain's heap, which wouldn't be allocated until the type is referenced.
  • (cs) in reply to John Smallberries
    John Smallberries:
    ammoQ:

    I wonder if a C# struct has some kind of "self awareness" like a class (carries type information with it) or if it leaves that to the compiler (like a C struct). Since there is no polymorphism with structs, the second option seems possible to me... or do I overlook something?

    They do carry type information. You can reflect over structs just like anything else in .Net.

    Boxing could theoretically make that possible even with structs that don't carry type information.

    In speaking to a friend of mine (thanks, Chris), he thinks that a .Net struct with all static members will simply have the int type descriptor and so would take up 4 bytes. The static members are simply scoped globals on the appdomain's heap, which wouldn't be allocated until the type is referenced.

    Interesting.
  • (cs) in reply to ammoQ

    ammoQ:
    John Smallberries:

    Does anyone care to comment on whether or not the VB compiler is doing the right thing? Does anyone still use VB? Does anyone care?


    Considering the nature of structs, a struct without non-static fields has a size of 0 bytes. I wonder how C# allocates an instance of such a struct.

    Maybe it puts in a dummy bool field called PleaseCompile...

  • (cs)

    Please dont ;)

    4.2 Choosing Between Class and Struct

    http://www.informit.com/articles/article.asp?p=423349&seqNum=2

     

  • (cs) in reply to ammoQ
    ammoQ:
    Gene Wirchenko:
    The above was a problem with, IIRC, Borland's C compiler.  printf() needs access to the FP library, because it handles FP.  If your program did not use any floats, the library would not be linked in.


    Why would the program crash then?


    I only have this secondhand, but with the Borland compiler, I believe that the linker would throw an error because of FP library references in printf() that it could not resolve.  It was a minor glitch, but a glitch nonetheless.

    Sincerely,

    Gene Wirchenko

  • (cs)
    Alex Papadimoulis:

      Public PleaseCompile As Boolean

    Give this guy some credit, at least he put into writing what we are all thinking when we hit that compile button.

  • (cs) in reply to chrismcb
    chrismcb:
    Alex Papadimoulis:
      Public PleaseCompile As Boolean

    Give this guy some credit, at least he put into writing what we are all thinking when we hit that compile button.

    He certainly did!  The apostate gave away one of the sacred mysteries!

    Sincerely,

    Gene wirchenko

  • The Simplifier (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    chrismcb:
    Alex Papadimoulis:
      Public PleaseCompile As Boolean

    Give this guy some credit, at least he put into writing what we are all thinking when we hit that compile button.

    He certainly did!  The apostate gave away one of the sacred mysteries!

    Sincerely,

    Gene wirchenko



    Is there really any data problem out there that needs more than plain old C?

    Is there any data problem that can't be solved without having to use structures?

    If you're going to "static" something, why not globalize it?

    Do it in an #include, comment the shit out of it.

    If the purpose of the newer languages is "Reusability" . .    Hah.

    Tell it to Einstein, Gallileo, Liebnitz, or, most of all Copernicus.

    I ain't in their class. . .   but, I'll tell you, I don't write code so that some bottom-feeder can "improve" on it.

    Somebody gives me a problem to solve?   I solve it.   Today.  Not Tomorrow, not next week.

    Today.

    I happened by an old employer recently. . .    They were still using programs I had written more than 15 years ago.

    Written in plain old Turbo C 2.0  . . .    Who hoo



    Most of these WTFs are related to "using the latest and greatest". . .

    G*d (pick your own diety (spelling) ) forbid. . .     that one would analyze a problem and  write a real solution.

    re: the WTFr who shut off parity checking. . .      Hopefully somebody wiggled the memory chips before going to the next step????

    Sincerely,

    NOT    Gene W
















































  • Scott S. McCoy (unregistered)

    I know very little VB, and a limited amount of basic.  Peronsally, I wouldn't consider that deprevation.  And the fact that alot of these posts are from VB "Engineers", tells me I'm probably more lucky, than deprived.

  • Scott S. McCoy (unregistered) in reply to pjsson

    And what authority on OO design is this from?  That's a curious, but really not accurate, statement.

  • adam k. (unregistered) in reply to Anonymous

    Uhm dood, has the programmer never heard of a union. gawwwwd.

  • (cs) in reply to wintermyute
    wintermyute:
    The real WTF here is the phrase "VB-deprived".


    s/VB-deprived/Lucky ones/
  • kelmi (unregistered) in reply to Bonds - steroids = me

    Which is easier:

    a) defining "object" without using the word "class"

    or

    b) defining "class" without using the concept of "object"

    ???

  • Anonymous (unregistered) in reply to Bonds - steroids = me

    And yet... you're wrong.  Classes are indeed objects.  No matter how you twist and turn it.  Everything's an object.  Why do you think they call it object-oriented programming and not object-and-class-oriented-programming...

    Allow me to convince you using a Smalltalk example.
    Let's take an instance of a string, namely 'hi'.  now check out 'hi' class.  This gives us the 'class' ByteString.  Now let's see what the class of ByteString is...  It's the ByteString class- class.  And the ByteString class-class is an instance of the MetaClass class, which in turn is an instance of   the MetaClass class-class...  And, believe it or not, this is an instance of... the MetaClass class!

    An object is indeed defined as an instantiation of a class, but since every class is also an instantiation of a class, every class is also an object.  QED.

    Obviously not every OO-language has a Meta-Object-Protocol as sophisticated as this of Smalltalk, but not every OO-language is as OO as Smalltalk either.  OO in its pure sense is all about objects, and classes too are objects.  Just think MetaLevel, like the first guy said.  He was right but probably got bored argueing.

  • Anonymous (unregistered) in reply to Bonds - steroids = me

    woops, I kinda meant to quote this guy... sorry!

    Anonymous:
    masklinn:

    Nope, a class is an object too, a metaobject to a regular object, an object that is a pattern of an object, an object factory if you want.

    And that's why people invented metaclasses, which are in fact the classes of classes (and you can instantiate a class from a metaclass, and then instantiate a regular object from the class instanciated from the metaclass).

    You are confusing your terminology, which is understandable. You do not instantiate an object, an object is an instantiation (of a class). This is OO 101.

    masklinn:

    What pjsson tells you is that in OO design everything is an object, there is no "but" and no "except", it's everything period.

    Now we do understand that Java does not have a clue, and doesn't understand that a class is an object, or a method is an object, etc (this is actually false BTW, you can manipulate java classes and methods as first class objects through java.lang.Class and java.lang.reflect.Method, but it's kind of awkward and I don't think java has metaclasses), but try to check languages such as Smalltalk, Python or Ruby and you'll see all kinds of wonders such as functions and methods being first-class object (e.g you can define one, pass it around, send it another method/function's argument, return one from a function, ...), classes being first-class objects as well, metaclasses (still first-class objects), ...

    A class is not "different", it's an object and an object factory, that's all there is to it.



    Being quite adept a python and ruby, I know exactly what you are talking about, but the fact remains, an object is an instantiation of a class. Think concrete implementation. They are different, but if you have to think of them as the same it won't hurt you at all.
  • (cs) in reply to Anonymous

    It should be mentioned in the "class vs object" discussion that OO languages exist which have no concept of "class", but use "prototype objects" instead - a new "instance" is rather a clone of the "prototype object"; inheritance is done by adding new fields and/or methods to an object etc.

  • Gorm Braarvig (unregistered) in reply to LuciferSam

    object/class an object is an illusion, a class is an illusion describing how you want your illusions to look like they behave, the meaning of the term "object" is there to make things easier, if you want your language to be exact in describing real field-derivative patterns, you do not program VB, and are not reading this. Therefore, the definition of "object" or "class" is not important beyond how helpful it is in developing. Hence, the object is not a class. hehe, just had to get out some bullshit, too...

  • Daniel (unregistered) in reply to tmountjr

    tmountjr:
    Think putting in a "<FONT size=2>Public PleaseGiveMeOneMillionDollars As Boolean</FONT>" statement will work, too? I mean, if the compiler is taking requests...

    Will return false :-((

  • (cs)

    Messing a bit with Alex's post:

    Alex Papadimoulis:

    Public Structure UserInformation
      Shared intUserID As Integer
      Shared strUserID As String
    End Structure

    Isn't trwtf here that VB's compiler doesn't let through the above? In C++ this compiles w/o any complaints:

    class Test
    {
        static int a;
        static int b;
    };

    Yes, it is just a dumb way to reinvent namespaces, but I see not real implementation reason to disallow this kind of constructs.
  • (cs) in reply to The Simplifier
    The Simplifier:

    Tell it to Einstein, Gallileo, Liebnitz, or, most of all Copernicus.

    I ain't in their class. . .   but, I'll tell you, I don't write code so that some bottom-feeder can "improve" on it.

    Somebody gives me a problem to solve?   I solve it.   Today.  Not Tomorrow, not next week.

    Today.

    I happened by an old employer recently. . .    They were still using programs I had written more than 15 years ago.

    Written in plain old Turbo C 2.0  . . .    Who hoo


    Sorry to burst your bubble, but about anyone can throw together a solution to a problem with a minimal amount of thought. And it does generally leads to more complex, messy and inefficient code. See, for instance, this very website for examples of what happens when you don't stop to think before coding.

    Making things maintenable, flexible, and able to grow past the initial specs requires thinking the architecture through. Just running head first into the most obvious solution doesn't cut it.
    It's a shame that there are people like you who are arrogant enough to think that maintaining and making a code base evolve is a lesser job than implementing it in the first place.
    I would guess that you somehow never had to do any maintenance, because that's where you get the knowledge and experience required to design something robust, and not something that people will be afraid to touch with a ten foot pole 15 years later.

    It's also when doing maintenance on existing code that you earn some humility, because you see how this boneheaded "let's just solve the problem instead of thinking" approach let to shitty code that performs sub-optimally and prevent you to implement all kind of cool and useful things later on.
    Then you realise that the real challenge is not to merely solve the problem at hand without thinking forward, but to make it simple, clear and efficient instead of indulging in half-baked and inefficient designs, that also usually leads to more complications everywhere in the end. (been there, done that, got the t-shirt)
  • (cs) in reply to Mikademus
    Mikademus:
    Messing a bit with Alex's post:
    Alex Papadimoulis:

    Public Structure UserInformation
      Shared intUserID As Integer
      Shared strUserID As String
    End Structure

    Isn't trwtf here that VB's compiler doesn't let through the above? In C++ this compiles w/o any complaints:

    class Test
    {
        static int a;
        static int b;
    };

    Yes, it is just a dumb way to reinvent namespaces, but I see not real implementation reason to disallow this kind of constructs.


    AFAIK, VB would compile it if it was a "Class" instead of a "Structure". Because of their very nature, static elements in a structure are kind of weird anyway.

    Zlodo:
    The Simplifier:

    Tell it to Einstein, Gallileo, Liebnitz, or, most of all Copernicus.

    I ain't in their class. . .   but, I'll tell you, I don't write code so that some bottom-feeder can "improve" on it.

    Somebody gives me a problem to solve?   I solve it.   Today.  Not Tomorrow, not next week.

    Today.

    I happened by an old employer recently. . .    They were still using programs I had written more than 15 years ago.

    Written in plain old Turbo C 2.0  . . .    Who hoo


    Sorry to burst your bubble, but about anyone can throw together a solution to a problem with a minimal amount of thought. And it does generally leads to more complex, messy and inefficient code. See, for instance, this very website for examples of what happens when you don't stop to think before coding.

    Making things maintenable, flexible, and able to grow past the initial specs requires thinking the architecture through. Just running head first into the most obvious solution doesn't cut it.
    It's a shame that there are people like you who are arrogant enough to think that maintaining and making a code base evolve is a lesser job than implementing it in the first place.
    I would guess that you somehow never had to do any maintenance, because that's where you get the knowledge and experience required to design something robust, and not something that people will be afraid to touch with a ten foot pole 15 years later.

    It's also when doing maintenance on existing code that you earn some humility, because you see how this boneheaded "let's just solve the problem instead of thinking" approach let to shitty code that performs sub-optimally and prevent you to implement all kind of cool and useful things later on.
    Then you realise that the real challenge is not to merely solve the problem at hand without thinking forward, but to make it simple, clear and efficient instead of indulging in half-baked and inefficient designs, that also usually leads to more complications everywhere in the end. (been there, done that, got the t-shirt)


    While I think you are generally right, the problem with your approach is that in too many projects, "thinking forward" is replaced by "following the mainstream / best practices / buzzwords" and "use the most complex architecture that might actually work".
    "Simple" and "clear" hardly appear in that context. Think of all those  projects which include EJB for no apparent reasons. (In my point of view, EJB targets the same kind of tasks like DCOM or Corba - distributed processing. That's where they should be used).
    This increases the complextity of the resulting system - by far - and introduces man "meta-languages" into the sytem.
    For example, to fully understand and control it, it's not suffient to know Java - you also have to know how all those frameworks are configured. It almost looks like every project is bound to include the superset of all technologies used in any project.
    If that happens - and it often happens - projects become complex, expensive and likely to fail. They do not any longer focus on the client's needs, but on fullfilling the buzzword checklist.
    If that happens, proponents of "quick&dirty" have a walk over - get rid of all the middleware, get rid of everything that looks complicated, just pop in some ASP (or PHP) pages with a few hard-coded SQL statements - voila, problem solved, job done.
    Finding an architecture that is really performant, reliable, cost-efficient, flexible and maintainable (readable) is the true art of software development.
  • (cs) in reply to limelight
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    User "Sammy" has UserId 42.
    strUserID might return "Sammy", intUserID 42.

  • wtf (unregistered) in reply to Anonymous Coward

    gotta love affirming the consequent

  • (cs) in reply to ammoQ
    ammoQ:
    While I think you are generally right, the problem with your approach is that in too many projects, "thinking forward" is replaced by "following the mainstream / best practices / buzzwords" and "use the most complex architecture that might actually work".
    "Simple" and "clear" hardly appear in that context. Think of all those  projects which include EJB for no apparent reasons. (In my point of view, EJB targets the same kind of tasks like DCOM or Corba - distributed processing. That's where they should be used).
    This increases the complextity of the resulting system - by far - and introduces man "meta-languages" into the sytem.
    For example, to fully understand and control it, it's not suffient to know Java - you also have to know how all those frameworks are configured. It almost looks like every project is bound to include the superset of all technologies used in any project.
    If that happens - and it often happens - projects become complex, expensive and likely to fail. They do not any longer focus on the client's needs, but on fullfilling the buzzword checklist.
    If that happens, proponents of "quick&dirty" have a walk over - get rid of all the middleware, get rid of everything that looks complicated, just pop in some ASP (or PHP) pages with a few hard-coded SQL statements - voila, problem solved, job done.
    Finding an architecture that is really performant, reliable, cost-efficient, flexible and maintainable (readable) is the true art of software development.


    I totally agree. but what I was talking about was writing and architecturing your own code right, not thoughtlessly relying on a bunch of toolkits and technologies to do things right for you.
    I'm working in video games, which is an application domain where a lot of projects can't use ready-made solutions or components for most things. So we don't have much "hey EJB is the new cool thing, let's use it everywhere from now on" kind of stupidity going on. We make up for it be being stupid in many other ways.

    The only two things for which middleware are often used are rendering and physics engines. To do everything else, you have to write a lot of code.
    And this bunch of code is usually, in my experience, painful to work with because people just throw together whatever they need for the task at hand without thinking whether their stuff might be useful to solve other related or similar problems. It then lead to reckless code reimplementation, cut & pasting, quick hacks to make something that was narrow-mindedly designed with a specific goal 'A' in mind able to also do a similar thing 'B'.
    You also usually have loads of code and data models duplicated between the tools and the game engine because you can't just make the game engine run within the tool, etc.

    And you end up with a messy, loose, quirky and hostile heap of code that could be ten time smaller, simpler and perform better.
    And of course, you throw most of it away for the next game because it's so poorly done and designed that it's full of game-specific behaviors, assumptions and hacks.
  • ancientlore (unregistered) in reply to wintermyute
    wintermyute:
    The real WTF here is the phrase "VB-deprived".


    I sooooo wish I was vb-deprived!
  • Uncle Bacon (unregistered) in reply to TheBaker

    A while back, a co-worker couldn't get inner queries to work properly. He was trying something like:

    select CustomerID from (SELECT CustomerID FROM Customers)

    • and not having much success. You should have seen the look on his face when I changed it to:

    select CustomerID from (SELECT CustomerID FROM Customers) Please

    • which ran first time. :)
  • Lucifersam's physcoanalyst (unregistered) in reply to LuciferSam
    LuciferSam:

    Maybe it was the way it was taught to me, but OO design didn't seem that hard.  I know people who graduated in my class that didn't know the difference between a class an object and a program.  That frightens me.

     

    [:^)]There are much scarier things in the world than that

     

    have you considered gaining a sens of proportion, life would be much less scary for you[8-)]

  • (cs) in reply to The Simplifier

    Is there really any data problem out there that needs more than plain old C?

    The Tao gave birth to machine language. Machine language gave birth to the assembler.

    The assembler gave birth to the compiler. Now there are ten thousand languages.

    Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

    But do not program in COBOL if you can avoid it.

    Is there any data problem that can't be solved without having to use structures?

    There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying: "What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure."

    If the purpose of the newer languages is "Reusability" . .    Hah.

    • A well-used door needs no oil on its hinges.
    • A swift-flowing steam does not grow stagnant.
    • Neither sound nor thoughts can travel through a vacuum.
    • Software rots if not used.

    These are great mysteries.

    Tell it to Einstein, Gallileo, Liebnitz, or, most of all Copernicus.

    A novice asked the Master: "Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?"

    The Master replied: "That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao."

    I ain't in their class. . .   but, I'll tell you, I don't write code so that some bottom-feeder can "improve" on it.


    Thus spake the master programmer:
    "Though a program be but three lines long, someday it will have to be maintained."

  • (cs) in reply to Anonymous

    Anonymous:

    An object is indeed defined as an instantiation of a class, but since every class is also an instantiation of a class, every class is also an object.  QED.

    You obviously failed logic, assuming you took it.  Your assumption that every class is also an instantiation of a class is WRONG.  F-.

    At some point in your chain, you have either a class that is purely a construct, call it GOD that is not defnined within your supposedly neat little view of the world.  It could be meta, or meta-meta, or meta-meta-meta, but it's there.

  • (cs) in reply to Otto

    Nice one Otto.

    It's true that there is no programming problem that can't be solved in C.  The same can be said of Assembly, and machine code.  It's just not always desirable to do that.   And if the exact same program is being used 15 years later, with no modifications, it could be that it does the job perfectly.  But it could also be that it doesn't do the job perfectly, and people want improvements to it, but it's so unmaintainable that it's simply not worth the risk or the effort to change it.

  • (cs) in reply to johnl
    johnl:
    Nice one Otto.

    It's true that there is no programming problem that can't be solved in C.  The same can be said of Assembly, and machine code.  It's just not always desirable to do that.   And if the exact same program is being used 15 years later, with no modifications, it could be that it does the job perfectly.  But it could also be that it doesn't do the job perfectly, and people want improvements to it, but it's so unmaintainable that it's simply not worth the risk or the effort to change it.


    It's a shame Otto doesn't want to cite sources he's going to copy and paste from.

    Sincerely,
    Richard Nixon

Leave a comment on “Please Compile”

Log In or post as a guest

Replying to comment #:

« Return to Article