• (cs) in reply to Mung Kee
    Mung Kee:
    masklinn:

    Nope, you can't just shoot yourself in the foot, you take out the whole leg from knee down. This is one of C++' awesomenesses.



    I once heard an old timer say in an interview a few years ago, "I liken C++ to a chainsaw.  You can get a lot of work done with it, but you can also f yourself up with it." <yes ,="" interviewer="" dropped="" f-bomb="" in="" the="" interview="">



    C
        You shoot yourself in the foot.
    C++
        You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "That's me, over there."

    MS-SQL Server
        MS-SQL Server’s gun comes pre-loaded with an unlimited supply of Teflon coated bullets, and it only has two discernible features: the muzzle and the trigger. If that wasn't enough, MS-SQL Server also puts the gun in your hand, applies local anesthetic to the skin of your forefinger and stitches it to the gun's trigger. Meanwhile, another process has set up a spinal block to numb your lower body. It will then proceeded to surgically remove your foot, cryogenically freeze it for preservation, and attach it to the muzzle of the gun so that no matter where you aim, you will shoot your foot. In order to avoid shooting yourself in the foot, you need to unstitch your trigger finger, remove your foot from the muzzle of the gun, and have it surgically reattached. Then you probably want to get some crutches and go out to buy a book on SQL Server Performance Tuning.

    FORTRAN
        You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception-handling facility.

    Modula-2
        After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.

    COBOL
        USEing a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to HOLSTER. CHECK whether shoelace needs to be retied.

    Lisp
        You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...

    BASIC
        Shoot yourself in the foot with a water pistol. On big systems, continue until entire lower body is waterlogged.

    Forth
        Foot yourself in the shoot.

    APL
        You shoot yourself in the foot; then spend all day figuring out how to do it in fewer characters.

    Pascal
        The compiler won't let you shoot yourself in the foot.


    370 JCL
        You send your foot down to MIS with a 4000-page document explaining how you want it to be shot. Three years later, your foot comes back deep-fried.


    FORTRAN-77
        You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you still can't do exception-processing.

    Visual Basic
        You'll really only appear to have shot yourself in the foot, but you'll have so much fun doing it that you won't care.

    Pascal (alternative)
        Same as Modula-2 except that the bullet is not the right type for the gun and your hand is blown off.

    Ada
        If you are dumb enough to actually use this language, the United States Department of Defense will kidnap you, stand you up in front of a firing squad and tell the soldiers, "Shoot at the feet."
        or
        The Department of Defense shoots you in the foot after offering you a blindfold and a last cigarette.
        or
        After correctly packaging your foot, you attempt to concurrently load the gun, pull the trigger, scream and shoot yourself in the foot. When you try, however, you discover that your foot is of the wrong type.
        or
        After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and confidently aim at your foot knowing it is safe. However the cordite in the round does an Unchecked Conversion, fires and shoots you in the foot anyway.
    Eiffel
        You create a GUN object, two FOOT objects and a BULLET object. The GUN passes both the FOOT objects a reference to the BULLET. The FOOT objects increment their hole counts and forget about the BULLET. A little demon then drives a garbage truck over your feet and grabs the bullet (both of it) on the way.
    Smalltalk
        You spend so much time playing with the graphics and windowing system that your boss shoots you in the foot, takes away your workstation and makes you develop in COBOL on a character terminal.
        or
        You send the message shoot to gun, with selectors bullet and myFoot. A window pops up saying Gunpowder doesNotUnderstand: spark. After several fruitless hours spent browsing the methods for Trigger, FiringPin and IdealGas, you take the easy way out and create ShotFoot, a subclass of Foot with an additional instance variable bulletHole.

    Object Oriented Pascal
        You perform a shooting on what might currently be a foot with what might currently be a bullet fired from what might currently be a gun.

    PERL
        You stab yourself in the foot repeatedly with an incredibly large and very heavy Swiss Army knife.
        or
        You pick up the gun and begin to load it. The gun and your foot begin to grow to huge proportions and the world around you slows down, until the gun fires. It makes a tiny hole, which you don't feel.

    Assembly Language
        You crash the OS and overwrite the root disk. The system administrator arrives and shoots you in the foot. After a moment of contemplation, the administrator shoots himself in the foot and then hops around the room rabidly shooting at everyone in sight.
        or
        You try to shoot yourself in the foot only to discover you must first reinvent the gun, the bullet, and your foot.or
        The bullet travels to your foot instantly, but it took you three weeks to load the round and aim the gun.

    Windows 3.1
        Double click the gun icon and wait. Eventually a window opens giving a selection for guns, target areas, plus balloon help with medical remedies, and assorted sound effects. Click "shoot" button and a small box appears with note "Unable to open Shoot.dll, check that path is correct."

    CP/M
        I remember when shooting yourself in the foot with a BB gun was a big deal.

    Access
        You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.


    </yes>
  • DS (unregistered) in reply to brazzy
    brazzy:

    Anonymous:

    (yeah, 3-tier, separation of logic and layout, blah blah).


    So you're above such widely accepted best practices? I pity your employers...


    For any useful dynamic web app you need to be able to inject data into the content.   As I said, such as printing variables and looping.  What's the purpose of  3 tier if the 3rd tier is just static content?
  • (cs) in reply to TheDauthi

    C# (and the framework, most people use them interchangably.  In theory, you can have one without the other...) is good if you know that your client has a decently mid-end windows-based machine, you don't care about being cross-platform

    Ahem, actually depending on how you write a C# app, it can be more cross-platform than any C/C++ app.  Take a look at Mono.  The apps you're probably talking about use, for example, System.Windows.Forms rather than GTK#.  That will, admittedly, result in a Windows-only app, but then the same thing will happen with a C++ app using MFC.

    C# (or any .NET app) is compiled to something like Java's bytecode, which is then compiled to a native image at runtime.

    As for performance issues, C# does have them.  Though MS will claim that since C# is self-optimising at runtime, you don't have to guess what hardware the user will have, and the way memory is handled will give you better memory performance than C++.  All this, according to MS, results in an app that is actually faster than C++.

    Ok, don't get too excited - I don't completely buy these claims.  Maybe when it's working better, but not yet.  The way I think of it is that C# takes a lot of control away from the developer, meaning its potential for performance isn't as good.  In the same way, C++ did the same thing with Assembly.  However, most developers (and I do mean most - exceptions are very, very rare) simply wouldn't know what to do with this control if they had it.  I wouldn't.  Most of my colleagues wouldn't.  And I doubt you would either.  (I don't know you, so I'm just making an educated guess - don't take it as me calling you a bad programmer or anything). 

    So what happens is that instead of using the extra control in C++ to speed up their app, they shoot themselves in the foot with it.  The fact is that computers are better at the memory management than the vast majority of humans, so unless you really are an exceptional programmer, you aren't going to do a better job than the computer.  So, in fact, unless you really are an exceptional programmer, there is no benefit to using C++ over C#, and there are lots of downsides.

    And it's not just that C++ offers more control than C#, you actually have to take that control.  Now, I'm sure that people in the past have had the same discussions about C vs Assembly, and C won out, didn't it?  Then people had discussions about C++ vs C, and C++ won out.  So, following that pattern now that we are having a discussion about C# vs C++... well, you do the math

  • DS (unregistered) in reply to masklinn
    masklinn:
    Anonymous:
    One of the greatest advantages of using php for web apps is the ability to embed code into html, even if it's just basic looping or printing variable values (yeah, 3-tier, separation of logic and layout, blah blah).  Trying to do this with Perl, even using one of the template modules, is awkward and clunky and a pain in the ass.  I remember once playing with Embedded Perl but that never really caught on, unfortunately.

    Ever heard of mod_perl and mod_python?



    what does mod_perl have to do with anything?

  • DS (unregistered) in reply to DS

    Nevermind, I found it.  I assume you were referring EmbPerl

  • (cs) in reply to johnl
    johnl:

    C# (and the framework, most people use them interchangably.  In theory, you can have one without the other...) is good if you know that your client has a decently mid-end windows-based machine, you don't care about being cross-platform

    Ahem, actually depending on how you write a C# app, it can be more cross-platform than any C/C++ app.  Take a look at Mono.  The apps you're probably talking about use, for example, System.Windows.Forms rather than GTK#.  That will, admittedly, result in a Windows-only app, but then the same thing will happen with a C++ app using MFC.


    Yes and no. System.Windows.Forms supports gets better in Mono and portable.net (for those who don't know: portable.net is another attempt to make a free .net implementation, part of the .gnu project).
    For simple apps, it's already "close to useable".  A part of my job is developing software for the .net compact framework; portable.net is already good enough to test it, mono is close to that. I would not use them for productive use (of apps using Windows.Forms) yet, because of some small usability issues; but I'm confident that in a few months these will be solved.

  • Jonathan (unregistered) in reply to AndrewVos

    am i a tool bc i made fun of VB or bc im a sore loser when it comes to being made fun about php?  why do u think there are such great web based apps in php? gallery? wordpress? phpmyadmin? etc etc etc there are too many to list, but i think php has a great user base.  clearly i dont look for asp based stuff, but even when i did do asp work, i still found better solutions to php.  i guess it comes down i like perl based languages, c, etc and i find microsoft to sell rubbish software really  

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    There is a difference between a hobbyist language and a language used primarily by hobbyists. Most things built in PHP are by hobbyists. Hobbysts generally do things much more poorly than professionals. Hence, there is a much higher percentage of bad PHP code than in other languages, like, say, PL/SQL, which I don't think anyone hobbies around in ...



    Then again, most of the examples you post to tdwtf are written by professionals.  Given the steaming turds you've shown us, I'm disinclined to believe that professional programmers are any better than mere hobbyists. [:)]

    (I'm joking.  Somewhat.)
  • (cs) in reply to johnl
    As for performance issues, C# does have them.


    You might be surprised how efficient .NET executables can be.  Sure C++ can outperform it, but be prepared to spend a lot more time on a C++ project versus C#(or VB.NET)

    Check out:
    http://www.codinghorror.com/blog/archives/000299.html
  • (cs) in reply to ammoQ

    I haven't looked at either of them in a while.  Mono seems to have better application support (for example, NAnt and NUnit are, AFAIK, built and unit tested with Mono, not Portable.NET).  However, the last time I looked at it, Windows Forms support wasn't working very well, which was (IIRC) the whole point behind GTK# - a GUI framework that wasn't as tied to Windows.

    As for what it's like to program with, I haven't a clue - I just know it exists and I've read the project descriptions.  I haven't really tried it for myself.

  • (cs) in reply to Jonathan
    Anonymous:
    am i a tool bc i made fun of VB or bc im a sore loser when it comes to being made fun about php?  why do u think there are such great web based apps in php? gallery? wordpress? phpmyadmin? etc etc etc there are too many to list, but i think php has a great user base.  clearly i dont look for asp based stuff, but even when i did do asp work, i still found better solutions to php.  i guess it comes down i like perl based languages, c, etc and i find microsoft to sell rubbish software really  


    No, you're a tool because you (1) don't spell out your words, (2) don't properly capitalize your sentences, (3) don't use contractions properly, (4) adopt the knee-jerk Microsoft bashing habits of a newly indoctrinated Linux zealot, and (5) generally annoy my sense of coherent semantics with your rambling, ill-formed sentences.

    I hope this answers your question.

    (This knee-jerk rant brought to you by bad coffee and too much refined sugar.)
  • (cs) in reply to mizhi
    mizhi:
    Anonymous:
    am i a tool bc i made fun of VB or bc im a sore loser when it comes to being made fun about php?  why do u think there are such great web based apps in php? gallery? wordpress? phpmyadmin? etc etc etc there are too many to list, but i think php has a great user base.  clearly i dont look for asp based stuff, but even when i did do asp work, i still found better solutions to php.  i guess it comes down i like perl based languages, c, etc and i find microsoft to sell rubbish software really  


    No, you're a tool because you (1) don't spell out your words, (2) don't properly capitalize your sentences, (3) don't use contractions properly, (4) adopt the knee-jerk Microsoft bashing habits of a newly indoctrinated Linux zealot, and (5) generally annoy my sense of coherent semantics with your rambling, ill-formed sentences.

    I hope this answers your question.

    (This knee-jerk rant brought to you by bad coffee and too much refined sugar.)


    you make a very strong case
  • (cs) in reply to Ytram

    You might be surprised how efficient .NET executables can be. 

    I doubt it - I work with .NET a lot.  I agree with you on this one, but I was talking about raw performance, and acknowledging that C# isn't as good at raw performance as C++.  But then, C++ isn't as good as C or Assembly.  The closer you get to machine code, the faster the language becomes, in terms of raw performance.  At least, in theory.  My point was that this theory doesn't always turn into a reality.

  • (cs) in reply to Ytram
    Ytram:
    As for performance issues, C# does have them.


    You might be surprised how efficient .NET executables can be.  Sure C++ can outperform it, but be prepared to spend a lot more time on a C++ project versus C#(or VB.NET)

    Best approach (as with every high level language with easy native code bindings, does C# have it?) being to get the best of both world by coding the complete application, profiling and recoding modules to native code only when necessary (time critical modules). It's probably the best compromise(even allowing you to keep your existing unit tests and validate native code modules against them), the only true loss versus compiled being memory footprint.

    Mostly useless if the interpreter implements a JIT compiler though

  • (cs) in reply to Jonathan
    Anonymous:
    but even when i did do asp work, i still found better solutions to php.



    Oh sure - there are many solutions to PHP, ASP is one of those solutions. [If you've got your heart set on using English to communicate your thoughts, you might want to take a course in it. There are numerous problems in your statement.]
  • cd (unregistered) in reply to dan
    Anonymous:
    Anonymous:


    I don't see what's so ugly about C.

    Two words: buffer overflow. C itself is a security hole.



    There are those that can code "C" and those that cannot.  C is not a security hole.  The programmer coding it needs to be detail oriented. 

    Most of the languages you code with now are probably built in C!

  • (cs) in reply to mizhi

    mizhi:
    Then again, most of the examples you post to tdwtf are written by professionals.  Given the steaming turds you've shown us, I'm disinclined to believe that professional programmers are any better than mere hobbyists. [:)]

    I do strive to only post production code written by professionals people who were paid to write it. And yes, sadly, I know quite a few hobbyist programmers who are magnitudes better than "senior-level" programmers I've worked with. Actually, now that I think about it, I've worked with 11-year olds on a BASIC compiler that were better coders than some of the "seniors" I work with ...

  • (cs) in reply to DS
    Anonymous:
    brazzy:

    Anonymous:

    (yeah, 3-tier, separation of logic and layout, blah blah).


    So you're above such widely accepted best practices? I pity your employers...


    For any useful dynamic web app you need to be able to inject data into the content.   As I said, such as printing variables and looping.  What's the purpose of  3 tier if the 3rd tier is just static content?

    I'm going to give you the benefit of the doubt here, and not just flame you for being a n00b or simply an obtuse idiot.

    Any non-trivial, data-driven web app benefits from n-tier architecture. The benefits are realized in terms of robustness, scalability and ease of construction & maintenance. If any of the tiers have static content, it would be the presentation tier, where dynamic data could be interleaved with HTML. The data tier moves data to/from the DB and the business tier(s) apply rules & security.

    This is pretty basic stuff, so I'm not sure what your issue with it is.
  • cd (unregistered) in reply to ammoQ
    ammoQ:
    <x &&j=""><y ;="" i++,j="" loop="" -="" but="" on="" other="" hand="" the="" ,="" also="" used="" to="" seperate="" function="" arguments="" so="" it="" is="" kind="" of="" overloaded="" (not="" in="" an="" oo="" sense="">
    Ugly languages give the programmer two dozens of guns with easy-to-pull tiggers so you can shoot yourself and all your coworkers in both foots. Hardly any other high-level language makes string processing - on the the most common tasks for computer programs - so dangerous like C.


    Dangerous?  Blahh.  If you code 'C' you know exactly where it stands strong.  You want to code something that is maintainable and yet powerful.  The next lower layer is to just code straight assembly.  But that makes for highly unmaintable code. 

    Too many guns and poor string management?  Give me a break.  That totally shows a lack of understanding of where 'C' excels.  We need 'C' in the world for building fast low-level and maintainable building blocks so that lazy fat-ass programmers can sit atop the structure and develop cool high-level applications.  If you feel the need for a going postal reference with 'C' you had better stay atop the developing structure.
    </y></x>
  • (cs) in reply to cd

    Yes, we need C.  We also need Assembly for the same reasons.  Doesn't mean that someone developing an ordinary, everyday end-user application (or even a framework or control set) should use it.

  • cd (unregistered) in reply to johnl
    johnl:
    Yes, we need C.  We also need Assembly for the same reasons.  Doesn't mean that someone developing an ordinary, everyday end-user application (or even a framework or control set) should use it.

    absolutely
  • (cs) in reply to johnl
    johnl:
    Yes, we need C.  We also need Assembly for the same reasons.  Doesn't mean that someone developing an ordinary, everyday end-user application (or even a framework or control set) should use it.


    IOW, the right tool for the job at hand.

    Some programmers approach a job with the "I have a hammer, so everything must be a nail" approach.
  • (cs) in reply to johnl

    johnl:
    Yes, we need C.  We also need Assembly for the same reasons.  Doesn't mean that someone developing an ordinary, everyday end-user application (or even a framework or control set) should use it.

    <FONT face="Courier New" size=2>in the perfect sans-serif world, this would be the case.  but alas, i am refactoring legacy code in c.  *sniff*</FONT>

  • (cs) in reply to Jonathan

    Anonymous:
    here here!

    I am also a coder that does PHP on a professional basis.  Yes I used to code in VB with ASP and HATED it.  I never tried ASP.net but i think its probably garbage as well.  I love PHP running on Apache servers.  I like reading wtf, as a lurker, only because I enjoy learning more coding and things not to um do.....but i find the php bashing a disappointment.  this site is truely a disappointment to me now, i can tolerate the vb code, as i just see it as vb bashing since vb is garbage anyways.  C++ is the only language to develop worthy code for applications.  C# doesnt even come close, sorry.     

     

    You must be a Troll, because no "Professional" developer would say this crap. 

  • (cs) in reply to christoofar
    christoofar:
    Anonymous:

    I don't see what's so ugly about C.


    Ok tell me, without going to google, what this code does:
    *snip*


    I'd say it renders the Mandelbrot set under X-Windows.
  • (cs) in reply to zinglons_ale
    zinglons_ale:
    christoofar:
    Anonymous:

    I don't see what's so ugly about C.


    Ok tell me, without going to google, what this code does:
    *snip*


    I'd say it renders the Mandelbrot set under X-Windows.


    Ahh, so you ran it through gcc? :)
  • (cs) in reply to cd
    cd:
    <x &&j=""><y ;="" i++,j="" loop="" -="" but="" on="" other="" hand="" the="" ,="" also="" used="" to="" seperate="" function="" arguments="" so="" it="" is="" kind="" of="" overloaded="" (not="" in="" an="" oo="" sense="">

    Dangerous?  Blahh.  If you code 'C' you know exactly where it stands strong.  You want to code something that is maintainable and yet powerful.  The next lower layer is to just code straight assembly.  But that makes for highly unmaintable code. 

    Too many guns and poor string management?  Give me a break.  That totally shows a lack of understanding of where 'C' excels.  We need 'C' in the world for building fast low-level and maintainable building blocks so that lazy fat-ass programmers can sit atop the structure and develop cool high-level applications.  If you feel the need for a going postal reference with 'C' you had better stay atop the developing structure.
    </y></x>


    Well, I can aggree to that. Unfortunately, C (and C++, which shares many of the problems) is also used for apps that are neighter low-level nor maintainable.
  • (cs) in reply to cd

    Anonymous:
    Too many guns and poor string management?  Give me a break.  That totally shows a lack of understanding of where 'C' excels.  We need 'C' in the world for building fast low-level and maintainable building blocks so that lazy fat-ass programmers can sit atop the structure and develop cool high-level applications.
    </Y></X>

    Speed is rarely as big an issue and C rarely as superior in that area as C programmers make it out to be. And maintainable? If anything, C tends to be less maintainable than most other languages. It IS good for very low-level stuff where you don't have the environment that higher-level languages usually require. By any means, code device drivers, operating systems and VMs in C. But IMO its usefulness compared to other languages declines rapidly beyond that.

  • (cs) in reply to ammoQ
    ammoQ:
    <x &&j=""><y ;="" i++,j="" loop="" -="" but="" on="" other="" hand="" the="" ,="" also="" used="" to="" seperate="" function="" arguments="" so="" it="" is="" kind="" of="" overloaded="" (not="" in="" an="" oo="" sense="">
    Ugly languages give the programmer two dozens of guns with easy-to-pull tiggers so you can shoot yourself and all your coworkers in both foots. Hardly any other high-level language makes string processing - on the the most common tasks for computer programs - so dangerous like C.


    Which is why Pascal is such a popular and wortwhile language. I see now, it all makes sense!

  • (cs) in reply to christoofar
    Java

    You read many pieces of literature and posts in various forums telling you how its impossible to shoot yourself in the foot in Java and how it's so wonderful because even stupid programmers can't shoot themselves in the foot. You also read that it's fast.

    You sit down with Java, point the gun at your foot, and shoot. You discover that it's just as easy and painful with Java as with anything else, it just takes a lot longer.

    Python

    You read some Python code about shooting yourself in the foot, and it's so obvious and such a joy to read that you don't feel the need to do it yourself.

  • (cs) in reply to DS

    Anonymous:

    For any useful dynamic web app you need to be able to inject data into the content.   As I said, such as printing variables and looping.  What's the purpose of  3 tier if the 3rd tier is just static content?

    You can do a presentation tier without mixing code with your HTML, and usually it will be better that way. As I said, Sun introduced JSP to allow Java programmers to sprinkle code in their HTML pages. Everything that came afterwards (Tag libraries, JSF) has been a move away from code sprinkles, strongly supported by the developers (the competent ones, anyway). That's why I find your statement that PHP's mixing code and HTML is so great so absurd.

    I think I just realized where you come from. If you think the alternative is writing code that generates HTML, as it was commonplace when webapps were all Perl CGI apps, then of course PHP is an improvement. But that was about 8 years ago. Technology has progressed since then. The currently prevailing paradigms are template engines or server-side components. You either minimize the logic on the page to the absolut minimum necessary to display preformatted data and do the rest (the actual application logic) in separate modules, or you have HTML-like tags that are rendered on the server and a surrounding framework that can interact with them in a way similar to "real" GUI widgets - even though they don't really exist on the client.

  • (cs) in reply to Mung Kee

    Mung Kee:

    Actually, you're statement is somewhat misleading.  There was and always will be an effort to keep the business logic out of the presentation layer.  A poorly written JSP contains scriptlets which often contain business logic.

    But that's exactly what he was proclaiming as PHP's great advantage - that it allows the equivalent of JSP scriptlets.

  • (cs) in reply to Omnifarious
    Omnifarious:
    Java

    You read many pieces of literature and posts in various forums telling you how its impossible to shoot yourself in the foot in Java and how it's so wonderful because even stupid programmers can't shoot themselves in the foot. You also read that it's fast.

    You sit down with Java, point the gun at your foot, and shoot. You discover that it's just as easy and painful with Java as with anything else, it just takes a lot longer.

    Python

    You read some Python code about shooting yourself in the foot, and it's so obvious and such a joy to read that you don't feel the need to do it yourself.

    Wow. Great job of sabotaging an attempt to humorously defuse the my-language-is-better-than-your-language bickering.

  • Muha Muha (unregistered)

    Maybe someone should tell the glorious WTF editor the difference between a plain variable array and an object.

    Of course it is really hard for a Java or whatever junkie to realize, that the world is not falling for your trap and is not using objects everywhere. You have to face it: neither $_SESSION, $_GET nor $_POST are objects. They are plain arrays... Using object to store mere datafields is just a waste of ressources.

  • BAADF00D (unregistered) in reply to hank miller

    Anonymous:

    Php puts everything into one namespace, and the internal functions have to consistency.   lsplit is useful, but it should be part of a string namespace (if not the object), not a top level. 

    i simulate namespaces in php by grouping static functions in class definitions. it's not perfect, but it certainly works to distinguish my code fomr other code (system or otherwise).

  • (cs) in reply to brazzy
    brazzy:

    Mung Kee:

    Actually, you're statement is somewhat misleading.  There was and always will be an effort to keep the business logic out of the presentation layer.  A poorly written JSP contains scriptlets which often contain business logic.

    But that's exactly what he was proclaiming as PHP's great advantage - that it allows the equivalent of JSP scriptlets.



    Misunderstood your post.  I get it now.  "Everyone thought it was good in JSP at one point too"
  • anonymous (unregistered) in reply to ominobufo
    So you prefer wasting limited bandwidth instead of wasting unlimited disk space?  Be realistic, whats a bigger expense? some hundred megs of disk space? or the bandwidth necessary to send and receive back data in hidden fields?

    Let's not forget, the second you use sessions, the back button on the browser doesn't actually do
    anything any longer. Clearly there is a trade-off. Sessions should only be used for storing data
    that must appear on every page, not simple form persistence that is best handled through
    HTML.

  • David F. Skoll (unregistered) in reply to Jonathan

    I program for a living, and developed a product whose Web interface is written in PHP.

    I have a love/hate relationship with PHP.  I love how easy it is to slap something together.  I hate the non-orthogonal library functions, the drive-you-insane inconsistency in function names, the change-APIs-every-release mentality so you don't know if you need pg_num_rows() or pg_numrows() without checking the PHP version number, the hidden gotchas like safe_mode making your app not work (or work weirdly), the WTF of opening URLs as if they were local files, the settings in php.ini that might or might not make your assumptions blow up in your face, the stupid "magic quotes" concept, ... uh....

    Suffice it to say that the Web GUI for our next project will not be written in PHP.

  • GrumpySimon (unregistered) in reply to David F. Skoll

    The real WTF is language fanboys:

    "PHP is for n00bs, Perl's ugly, VB's for MS drones....etc".

    NO-ONE CARES.

    They're all tools, folks. Use what works well for you & the current project.

    ...and you ruby zealots are the WORST.

    --Simon

  • (cs) in reply to Muha Muha
    Anonymous:
    Maybe someone should tell the glorious WTF editor the difference between a plain variable array and an object.

    Of course it is really hard for a Java or whatever junkie to realize, that the world is not falling for your trap and is not using objects everywhere. You have to face it: neither $_SESSION, $_GET nor $_POST are objects. They are plain arrays...


    They most certainly are not. Ever seen a "plain array" with string indices? Those are hash tables supported at the language level. Objects, basically.

    Anonymous:

     Using object to store mere datafields is just a waste of ressources.


    You seem to have a deep-seated trauma about objects, and very little knowledge of what they are. Objects are simply a way to group data together with the code it operates on. How exactly that is implemented differs between languages, but in Java, for example, the overhead compared to the "raw" data as you'd have it  in a C struct, is 8 bytes (on a 32 bit Sun JVM). Unless you have a huge amount Objects with very small data fields (rarely necessary since you can also use arrays, which are objects as well), that's pretty irrelevant. Besides nowadays programmer time is a much costlier resource than RAM or CPU ticks.

  • (cs) in reply to christoofar
    christoofar:
    zinglons_ale:
    christoofar:
    Anonymous:

    I don't see what's so ugly about C.


    Ok tell me, without going to google, what this code does:
    *snip*


    I'd say it renders the Mandelbrot set under X-Windows.


    Ahh, so you ran it through gcc? :)


    Actually, I realized it was an IOCCC entry by its form, noticed that the code spells out Z -> Z2 + C (which is the general form of the Mandelbrot set) and that it had various calls to Xblahblah in it.

    Although I ought to give it a whirl sometime to see how it looks!
  • Phil D (unregistered) in reply to hank miller

    hank miller:


    ...More complex forms of this are very useful:
    if (a = doSomething() && b = doSomethingElse(a))
       ...
    Of course you walk a fine line between making your code more readable because more of the function fits on the screen at a time, and making your code harder to read because you are doing odd things. 

    I have used C and C++ a fair bit, and like it OK, but do have to agree with some of what's been written in this thread, regarding usability.

    For example, the statement above, actually result in undefined behavior. Here's why: The value of doSomething() is not guaranteed to get written back to the variable 'a', before 'a' is passed into the doSomethingElse() function. (There needs to be something called a 'sequence point' in between).

    In this way, C and C++ really don't meet programmers initial expectaions in many ways. A lot of these issues are due to (perhaps outdated) performance considerations. The best advice it to be careful and not try anything 'fancy'. Even if it appears to work today, it may not work tomorrow.

  • (cs) in reply to Mung Kee
    Mung Kee:
    discobean:
    Satanicpuppy:

    I prefer to just skip the whole mess wherever possible and dump it into a database.


    WTF does that mean?


    What?!  You've never used the database for session management?  haha


    You know I use php a decent amount, mainly because it's so widely available, and cheap hosting is a breeze. I kinda bristled a little bit when people startign going on about it being a "Hobbyist Language".

    But after seeing this thread, and witnessing the massively large number of ill-informed comments defending php, I have to think that maybe it IS really just a hobbyist language. People don't understand arrays, people don't understand session management...This is basic stuff. The people saying these things would be helpless working with Java or C#, where there's more than one kind of datastructure.

    Php is good for driving database webapps. It's easy to deploy, and easy to code. I use php because I find it a useful tool. It's not a wonder tool. It doesn't solve all my problems, and it's not appropriate for every usage...not even close. People need to get over the idea that there's one language out there thats going to solve all their problems.

  • (cs) in reply to christoofar
    christoofar:
    <yes ,="" interviewer="" dropped="" f-bomb="" in="" the="" interview="">
    {language foot shooting breakdown}

    </yes>


    Much enjoyed. Thank you.


    I would like to add;

    Javascript
    You download a gun from the internet, but it won't fire unless you fully load it. Depending on the Gun Type Definition, bullets may go in a different direction than was actually aimed at, usually into someone else's foot.
    You can only shoot your foot if you fire it yourself. If someone else shoots at your foot, the gun shoots their foot instead. Then the W3C pulls up in a black sedan and shoots the feet of everyone in the room.

    HTML
    You support the gun with such a huge table that you can't reach the gun anymore. You're permanently safe.

    CSS
    The gun only hits if you point it at certain feet. Some feet will ignore the bullet because they do not support it. If pointed at other feet, it will shoot out the back. In a special case, it will fire two bullets. Out the back.
  • krftsman (unregistered) in reply to md2perpe

    No one I know would type the entire path to the session variable unless they were developing some sort of control; and then, they would simply put Using System.Web in the list of namespaces.

    When developing "normal" asp.net apps, Session["admin"].ToString works just fine.  Or, alternatively, (right or wrong) you can write (string)Session["admin"] if you don't feel checking to see if the session object in question is null and do not feel like throwing/dealing with an exception.

    And if that ain't enough, $_AT $_LEAST $_THE $_CODE $_IS $_NOT $_RAMPANTLY $_FILLED $_WITH $_DOLLAR $_SIGNS $_AND $_UNDER $_SCORES.

    Never mind difficulty reading all caps, anyone ever hear of Carpal Tunnel Syndrome.

  • (cs) in reply to johnl
    johnl:

    C# (and the framework, most people use them interchangably.  In theory, you can have one without the other...) is good if you know that your client has a decently mid-end windows-based machine, you don't care about being cross-platform

    Ahem, actually depending on how you write a C# app, it can be more cross-platform than any C/C++ app.  Take a look at Mono.  The apps you're probably talking about use, for example, System.Windows.Forms rather than GTK#.  That will, admittedly, result in a Windows-only app, but then the same thing will happen with a C++ app using MFC.


    Yes, I'm aware of Mono.  I like it quite a bit, but having played with it, I could not in good faith roll it out to production, as an earlier poster said.  And there are still patent issues: while Mono is safe as far as the ECMA standard goes, implementing some of the .NET libraries may be problematical.  And there may be problems to both .NET and Mono from Sun due to some patents that may apply to Java.

    johnl:

    C# (or any .NET app) is compiled to something like Java's bytecode, which is then compiled to a native image at runtime.

    As for performance issues, C# does have them.  Though MS will claim that since C# is self-optimising at runtime, you don't have to guess what hardware the user will have, and the way memory is handled will give you better memory performance than C++.  All this, according to MS, results in an app that is actually faster than C++.


    The performance issues are, in the general application case, not significant compared to developer time.  I do worry about the start-up times, but that's true in Java, too. However, it does require a decent machine to run on: the P3-500s, 128 MB ram that carry the people I develop for are often not good enough to run complex C# applications.  (I just tried re-writing a legacy app because of requirements changes, and much thrashing ensued) Of course, you could ask why we're using 5-6 year old tech, but they still work for all of the C++, perl, Java and even VB that gets churned out.

    It is definitely possible that C# can be faster than non-managed C++ in some cases.  The same can be true for many languages that run "on top of something", as in the case of Java and C# with their VMs and perl and lisp in the case of their interpreters, because the algorithm can be optimized at runtime.

    johnl:

    Ok, don't get too excited - I don't completely buy these claims.  Maybe when it's working better, but not yet.  The way I think of it is that C# takes a lot of control away from the developer, meaning its potential for performance isn't as good.  In the same way, C++ did the same thing with Assembly.  However, most developers (and I do mean most - exceptions are very, very rare) simply wouldn't know what to do with this control if they had it.  I wouldn't.  Most of my colleagues wouldn't.  And I doubt you would either.  (I don't know you, so I'm just making an educated guess - don't take it as me calling you a bad programmer or anything).

    Actually, I'm probably the exception to the rule.  One of my primary hats is to write code for call center IVRs, which requires, at times, fast system-level code.  The difference between half a second and 2 seconds is huge when your customer is listening to dead air, or even hold music, while you grab data.   (That's also 2 seconds per call, et minima, which over the course of a year comes to around $9-11k) I regularly deal with things at the byte level for communications with our phone switch, as well, another time at which performance matters.  I also have to deal with a certain amount of encryption to pass data around, and at other times I have to parse 1G mainframe files in seconds.
    Basically, you're right, though, that most people don't need it, just like they don't need to be absolutely sure that memory is released right at the point when they Dispose(), and instead leave it up to the GC.  And in those cases, and so long as they also don't need to ensure that it'll run on OSX and Linux, use C#.  It's the right tool for the job.

    johnl:

    So what happens is that instead of using the extra control in C++ to speed up their app, they shoot themselves in the foot with it.  The fact is that computers are better at the memory management than the vast majority of humans, so unless you really are an exceptional programmer, you aren't going to do a better job than the computer.  So, in fact, unless you really are an exceptional programmer, there is no benefit to using C++ over C#, and there are lots of downsides.

    This definitely happens.  Which is why someone said earlier to write most everything in a higher-level language then drop to C++ or C to finish up.
    Or you use C++ to manage your memory with autoptrs, OAII, and, well, plain old good design.

    johnl:

    And it's not just that C++ offers more control than C#, you actually have to take that control.  Now, I'm sure that people in the past have had the same discussions about C vs Assembly, and C won out, didn't it?  Then people had discussions about C++ vs C, and C++ won out.  So, following that pattern now that we are having a discussion about C# vs C++... well, you do the math



    Assembler is still used for some things, I have a class wrapper I use for searching that drops down to that level (part of the application that parses 1GB files in about a second).  But C and C++ are definitely not dead, even as application languages: look at the mass of code that gets pushed out by the open source community.  And there are a very large number of legacy applications that use it.  And there are companies such as mine that encourage new development to be done in C++ over C#. 

    Don't misunderstand, I'm really trying to say there are different tools for different jobs, and you should choose the right one.  Assembler is the laser-etcher, C/C++ are precision toolkits, Java is the slotted screwdriver (you can use it in both types) C# is the phillips-head screwdriver, perl is a swiss army knife, VB is a hammer (when you don't need as much precision but need it done quickly).  PHP is your dremel cutter: used by hobbyists a lot, often to screw up some piece of metal, but occasionally used for industrial work, too.
  • Anonymous (unregistered) in reply to anonymous
    Anonymous:
    Let's not forget, the second you use sessions, the back button on the browser doesn't actually do anything any longer.

    Besides the whole "going back" thing that it normally does...

  • nobody (unregistered)

    if you want to see really bad php code go there: http://www.dynamic-webpages.de/20.foren.php?threadID=6323&betreff=Werte+in+Arrays+vertauschen+aus+anderem+Array&forum=PHP3&kat=1 the post by "Evil Code Monkey" on 19.10.2004 (d.m.y)

  • (cs) in reply to TheDauthi

    I like it quite a bit, but having played with it, I could not in good faith roll it out to production, as an earlier poster said. And there are still patent issues: That poster also said that, in a few months, Mono will be "good enough". Though his idea of "good enough" may be different to yours.

    Actually, I'm probably the exception to the rule Fair enough. I had to cover the possibility that you were doing something that just wouldn't work in .NET or that you really were that good.

    Assembler is still used for some things, I have a class wrapper I use for searching that drops down to that level (part of the application that parses 1GB files in about a second) Indeed, and I mentioned this in a later post. I was talking more about the general end-user app type thing.

    In the past decade, C++ has taken a lot of jobs over from Assembly. Things that used to be the domain of Assembly (and later, C) are now done in C++. However, C# is now doing the same thing to C++. Things that were done in C++ are now being (increasingly) done in C#.

  • (cs) in reply to johnl

    Damn thing doesn't work in IE7...

    Anyway, forgot this bit

    And in those cases, and so long as they also don't need to ensure that it'll run on OSX and Linux, use C#. It's the right tool for the job.

    Personally, I disagree with the Linux bit to a certain extent. I dunno, really, not having looked at Mono that much (other than keeping a general track on the project). My boss thinks it's doomed to failure, but I disagree. I think MS have a head start on them, for sure, but they are (slowly) catching up.

Leave a comment on “Sessionrific! ”

Log In or post as a guest

Replying to comment #:

« Return to Article