ZOMBIE FORUMS

It's a stinking, shambling corpse grotesquely parodying life.
It is currently Thu Mar 28, 2024 4:05 am

All times are UTC - 8 hours [ DST ]




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 52 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Programming languages! ... or, "why be original?"
PostPosted: Fri Mar 18, 2005 4:15 am 
Offline
Native
User avatar

Joined: Wed Dec 11, 2002 5:00 pm
Posts: 869
Over in the Unrelated topic, I donned metaphorical asbestos panties to say that I don't like C++. Here, I don't need the panties. I'll go metaphorically commando and admit that I really, really, really despise C++. Even one of the language's defenders in that forum (OmnipotentEntity, I believe) called it "a behemoth". Let's examine it in detail.

Once upon a time, an AT&T researcher named Bjarne Stroustrup wanted a language with which to do simulations programming. He didn't have a Smalltalk environment handy so he and his chums wrote a preprocessor for a language which he called "C with Classes". That was all it was: it added code attributes to C's existing product-type facility, which is called "struct" in C. It did not address any of C's weaknesses, such as weak pointer typing or resource allocation. It was a graft on the side of C, and that was all it was ever supposed to be.

Now, other people at AT&T wanted to try out this new object-oriented stuff too, so they got Stroustrup to add more and more features to this new language of his. Somewhere in there, it got renamed from "C with Classes" to "C++". First, Stroustrup added multiple inheritance to the language. Then, he added ad-hoc genericity. Then, he added exception handling and run-time type identification. He should have added those features in exactly the opposite order, but he didn't, so as time went on the language got more and more and more baroque.

Still, the primary design motive for C++ was binary compatibility with C. C++ never acquired compiler-managed resource allocation, and because C++ programs have to be able to link with C programs, it never can. It now comes with a standard library of generic container classes and algorithms on those container classes, which takes care of many of the problems with resource allocation -- but by no means is the entire problem gone.

Meanwhile, people outside AT&T wanted to try out this new language, too. I was one of them; I saved up my allowance for many months to buy the first version of Borland Turbo C++ as soon as I could. (I was a weird kid, okay.) The language got so popular that it spawned many dialects, and programs written for one compiler required very heavy tweaking even to compile properly on another, let alone link and run. People demanded a standard, and for their sins, one was given to them.

Standards committees are committees. The C++ language was already beastly, but after standardisation, it has become ridiculously unwieldy. It is so unwieldy that as I write this, no compiler adheres to the entire standard even seven (I think) years after it was published. (G++ comes close, though.) Furthermore, because of pressure from industry, the standard was released far too early and therefore makes C++ harder to use, not easier.

More corollaries of the binary-compatibility-with-C rule: firstly, it turns out that programs compiled with one C++ compiler will not link with object files of programs compiled with other C++ compilers. Microsoft may love this state of affairs, because it means that if I want to use a library that was compiled with MS VC++, I have to purchase MS VC++, but ordinary people do not love spending large amounts of money on redundant, ill-written compilers. (MS VC++ is not a good compiler, compared with IBM's or GNU's, and its development environment pales in comparison with Emacs.) Secondly, it makes for nightmarish versioning problems. If I change the interface of any one class in a program, I will likely have to compile the entire program again. Imagine having to wait for eight-hour compile cycles each time you find and squash a bug.

That is not to say that there is nothing good about C++. One very accidental feature of C++ is that a C++ compiler is an interpreter for a very strange functional language which has come to be called "template metaprogramming". That is, a C++ program can be a program to generate new C++ programs at compile time, which is weird, but amazingly useful in certain circumstances.

And, yes, compiled C++ programs are fast. That is, if they don't have any bugs in them. Since it is so hard even to compile C++, a program that even theoretically has no bugs in it may fail to work properly after being processed by any given compiler. That is not to diminish the difficulty of writing correct C++, either, especially given the monstrously complicated rules governing exception handling.

There is a place in this world for a good, compiled systems programming language that allows the programmer much leeway and control. It would be nice if that language were object-oriented, because OO design is fashionable these days, but it probably doesn't need to be.

Hey! I know! Why don't we use C ....


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 18, 2005 7:41 am 
Offline
Addict
User avatar

Joined: Fri Nov 08, 2002 5:00 pm
Posts: 4439
Location: You can't take the sky from me. Since I found Serenity.
Someone needs to break Godel's uncertainty theorem and find a way to make P. And spec it correctly.

But until the day when we can violate the laws of logic at will, I'll probably wind up using C++ for things I need to compile.

I think it's major problem is that alot of people wanted it to be easy to use for different things. So, in the true bureaucratic way, it mediocre in all of those things because of the compromises necessary.

_________________
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 18, 2005 10:42 am 
Offline
User avatar

Joined: Sun Jan 17, 2038 9:00 pm
Posts: 3209
Tamayo, who may or may not be the love of my life, wrote:
(MS VC++ is not a good compiler, compared with IBM's or GNU's, and its development environment pales in comparison with Emacs.)


Tamayo, I love you. Too bad I don't know enough to understand exactly what the hell you're talking about, though; give me another year or two of CS classes... bastards, making me have to wait before I can actually change my major.

-- Barry, the vi-hater

(and yes, the first thing I did during a CS exam where I was forced to use a goddamn iMac (it's Carnegie Mellon. you'd think they'd use something better than iMacs for the CS machines... Linux desktops or SOMETHING. OSX is decent, but the mouse and keyboards are so bad. worse than laptop keyboards, for chrissakes.) was figure out how to set the meta key in a terminal so I could use Emacs instead of goddamn CodeWarrior. pfffft.)


Top
 Profile  
 
 Post subject: Re: Programming languages! ... or, "why be original?"
PostPosted: Sat Mar 19, 2005 11:47 pm 
Offline
Addict
User avatar

Joined: Thu Sep 04, 2003 9:43 pm
Posts: 1096
Tamayo wrote:
There is a place in this world for a good, compiled systems programming language that allows the programmer much leeway and control. It would be nice if that language were object-oriented, because OO design is fashionable these days, but it probably doesn't need to be.

Hey! I know! Why don't we use C ....

Ewww. ...

I direct your attention to the popular <a href="http://www.gtk.org/api/2.6/glib/index.html">GLIB</a> API. GTK+ is a core part of the GNU cross-platform environment (The Linux-specific GNOME libraries are based largely on it.), so it follows the GNU coding standards. As noted, C++ source can be somewhat non-portable between compilers, and static C++ libraries are totally linker-incompatable[1]. Thus, the GNU standard states, <a href="http://www.gnu.org/prep/standards/html_node/Source-Language.html#Source-Language">the prefered language for development is C</a>.

Ugh. This is all good and well for building lovably ugly UNIX-like commandline appplications, but for big architectures like a GUI, you need an object oriented structure to organize the API so that it fits in the brain of an average human programmer. Enter GLIB. GLIB/GTK+ essentually implements an object oriented structure on top of C. It works, but it's about as elegant as a rhino in heat.

My point is, there is a nitche were speed is an issue but SOME sort of high-level language feature is needed to manage code complexity. In the Unrelated thread, someone pointed to scientific/high performance computing as an example of successful use of C++. Of course OpenMP and MPI are C and FORTRAN[2] standards, not C++. When you're seeking the level of performace that requires the use of a parallel system, the extra pointer lookups you can incur with C++ become significant. The fact that large HPC applications ARE being written in C++ suggests to me that the programmers could not make a high level language fit into the performance constraints, but also were not willing or able to spend the extra time to write the code in pure C or FORTRAN.


_______
[1] Having spent most of a week trying to track down a linker problem, I agree 100% with Tamayo. C++ name mangling is insane, and I really don't understand why a standard approach to mangling was never included in the spec.

[2] FORTRAN is alive and well in the high performance computing community. As I understand it, the explicit lack of pointers in the language allows the compiler to make additional assumptions about when and where variables might be changed, leading to more aggressively optimized code. Many numerical packages wind up written in FORTRAN for this reason.

_________________
Always watching, ever vigilant


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 20, 2005 12:34 am 
Offline
PostWhorePornStar
User avatar

Joined: Fri Jan 17, 2003 5:00 pm
Posts: 7672
Location: Tallahassee, FL
Something I just said in unrelated and I'll say it here - the WinNT core was coded in C++. Obviously, it has some use.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 20, 2005 11:08 am 
Offline
User avatar

Joined: Sun Jan 17, 2038 9:00 pm
Posts: 3209
krylex wrote:
Something I just said in unrelated and I'll say it here - the WinNT core was coded in C++. Obviously, it has some use.

Creating security holes so large you can drive a dump truck through them?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 21, 2005 3:35 am 
Offline
Native
User avatar

Joined: Wed Dec 11, 2002 5:00 pm
Posts: 869
The Baron wrote:
anyway, Tamayo, if there are alternatives to C++ that are so much better (yes, I just glanced at Objective C, it seems pretty. Like C!)... why are we still wasting our time with it? is it a simple matter of "Well, we didn't have anything better for a while, so now we've got a lot of crap written using it, and a lot of people know it, so it would take too much time to make everyone switch?" or is it just that most people don't really care (or even realize that alternatives exist)?


I think we're still "wasting time with it" for much of the first reason you name, but the "lot of crap written using it" includes some very interesting stuff like Id Software's games. As has been pointed out, compiled C++ programs can run very quickly. Games programmers, scientific programmers and other people who want speed with their object-orientedness and care less about robustness or predictability of use go for the language that supplies those requirements the best and that has much useful documentation for it. Objective C is a good language, but modern graphics libraries are written in C++ and documented for C++ programmers; it is even the case that algorithms are designed with C++'s strengths and weaknesses in mind. If you want to work for Id Software, you write C++.

Yes, there are alternatives, which take account of the fact that programmers' labour is quite expensive. If by using some language X, the programmers in my organisation can produce software that works and is fast enough, pretty enough and secure enough for its users, then X is the language they should use. Java has trouble with the "fast enough" requirement, and naturally since Microsoft decided not to support Java 1.2 in the IE browser, Java's acceptance is that much more limited. C# is Microsoft-only, which means it might not be "secure enough. ;-) C, however elegant it is, is a language designed for writing operating systems; it is not really suited for very large projects or very complex algorithms. (People have used it for such, of course, and often -- because they like it.)

PHP works quite well for building active web pages. Perl is unmatched for crunching relational databases, though it has good competition in Python. Smalltalk is used all over the American banking system to build object-oriented databases -- and, of course, it is the language for simulations. Visual Basic makes writing GUIs for Windows fairly easy. And so on.

Use the tool appropriate to the job. C++ is a tool, and for certain tasks, it is appropriate. It could be a better tool, yes; but it works. For tasks outside its purview, though, other tools are far better. For example, the processing cycles one can save by writing a database manager in C++ rather than Perl are completely irrelevant because database programs are always waiting for disk accesses, so the (relative) safety and convenience of using Perl rather than C++ is emphasised. By contrast, the very most time-critical parts of a video game are often written in assembly language.

Personally, I have come to like functional languages. Type safety, computer-managed resource allocation, equational reasoning, implicit parallelism, and just plain neato-ness are attractive to me. A compiled program in Haskell or Clean or O'Caml will run an order of magnitude more slowly than a program in C or C++ that does the same thing, but it probably won't ever dump core.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 21, 2005 6:27 am 
Offline
PostWhorePornStar
User avatar

Joined: Fri Jan 17, 2003 5:00 pm
Posts: 7672
Location: Tallahassee, FL
The Baron wrote:
krylex wrote:
Something I just said in unrelated and I'll say it here - the WinNT core was coded in C++. Obviously, it has some use.

Creating security holes so large you can drive a dump truck through them?


That's not C++'s fault. That's the fault of Microsoft and its programmers. We need more people like the programmers that write software for the space shuttle. I can't find the news story offhand, but I will link it as soon as I do. In essance, these people are flawless programmers. If they leave a bug in their software, its a multi billion dollar mistake and people lose their lives. When they have a bug, they don't just fix it. They go all the way back to the drawing board if needed to find out how the problem was even let to exist, let alone perpetuate itself however far down the line.

The problem with Microsoft is they rus things out and seem to have absolute zero legal liability (for some reason unknown to me) over the product they release. Thats why there are so many security holes. Thats why there is so much shit and so few actual versions of software. They simply have the power to do pretty much whatever they want, and as of right now, there is no competition.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 21, 2005 12:02 pm 
Offline
Expatriate
User avatar

Joined: Fri Oct 15, 2004 9:44 pm
Posts: 134
Location: Screaming obsenities regarding untestable C++ software.
krylex wrote:
That's the fault of Microsoft and its programmers. We need more people like the programmers that write software for the space shuttle.


NASA has deep enough pockets to pay for computers with multiple levels of redundancy. They can pay for a small army of test engineers to not only test every system and every feature, but every possible interaction between systems and every combination of features. They can pay for programmers to write the program, then spend more time writing millions of simulations that test every single line of code.

On the other hand, how many homes lack adequate firewalls, *any* wireless network security, up-to-date virus protection, or even backups/hardcopies of sensitive information?

_________________
"Their need for total domination and to bring the world to the edge of utter apocalypse makes them less-than-ideal Jenga partners."


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 21, 2005 1:56 pm 
Offline
PostWhorePornStar
User avatar

Joined: Fri Jan 17, 2003 5:00 pm
Posts: 7672
Location: Tallahassee, FL
The team that writes and tests the software at NASA is less than 10 or 15 people. Its not an army of programmers. Its a few damned good ones.

Now, I agree that most homes are unprotected because people are stupid.

However, what is pretty much the largest company on the face of the planet? It makes more money in a quarter than a great deal of nations of the world do in a year.

I'll give you a hint, Billy Gates is the principal shareholder.

Now, if you have that kind of money, you could have better programmers putting out more efficient code. They don't care about overall efficiency, as they don't have to. There isn't anyone to compete with them and no lives are in direct peril.

Also, about security in code and stuff like that, this thought just came to mind - Don't blame the language. Blame the coder.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 3:52 am 
Offline
Native
User avatar

Joined: Wed Dec 11, 2002 5:00 pm
Posts: 869
krylex wrote:
Also, about security in code and stuff like that, this thought just came to mind - Don't blame the language. Blame the coder.


I am in total agreement with this sentiment. A worker who blames his or her tools for his or her own failures is a very poor worker. Conversely, a worker who brings the wrong tools to a job site is also a poor worker. Electron microscopes, while unsurpassed for examining tiny things, are poor substitutes for hammers and screwdrivers. And even if for some reason you need to examine a tiny thing on your construction site, it's probably good enough to use a magnifying glass or even an ordinary optical microscope; the vast expense and utter fragility of electron microscope makes bringing them to construction sites ... well, I think I've stretched this analogy further than its breaking point. ;-)

I've been negative enough. Now, let me suggest an alternative: functional programming. I'll show you a little program ...

Code:
{- -*- Haskell -*- -}

module Example(qsort) where

qsort :: Ord a => [a] -> [a]
qsort []     = []
qsort (x:xs) = qsort [y | y <- xs | y <= x]
               ++ [x]
               ++ qsort [y | y <- xs | y > x]


Pretty nice, hm? Short, sweet, to the point, and totally usable. By contrast, let's just look at the same algorithm in another context ...

Code:
// -*- C++ -*-

#include <algorithm>
#include <functional>
#include <vector>

template <class T>
inline void qsort(std::vector<T>& xs,
                  const std::binary_function<T, T, bool>& le
                                                      = std::less_eq<T>(),
                  const std::vector<T>::iterator l = xs.begin(),
                  const std::vector<T>::iterator h = xs.end())
{
    if (h - l <= 1) return;

    std::vector<T>::iterator i = l + 1;
    std::vector<T>::iterator j = h - 1;

    while (i < j) {
        while (le(*i, *l) && i < j)
            i++;
        while (!le(*j, *l) && i < j)
            j--;
        std::swap(*i, *j);
    }
    std::swap(*l, *j);
    qsort(xs, le, l, j - 1);
    qsort(xs, le, j + 1, h);
}


Am I being fair? Not entirely; the fact that Quicksort is a one-or-two-liner in a functional language has much to do with the fact that lists and operations upon them are built-in language features in most functional languages. Then again, lists and operations upon them are built-in language features in most functional languages. ;-)

Now, you may point out that a better implementation of Quicksort than mine above already exists in the C++ standard library. Well, there's a sort in the Haskell prelude, too, and it's more highly tuned than the one-liner is. Sorting algorithms, too, are fairly simple and easy to code in whatever language. I'll post some code tomorrow; I'm exhausted now.

Edit1: BUG! *winces*
Edit2: TYPO! (I'm not as good at programming without sleeping as I was once, it appears :-( )


Last edited by Tamayo on Tue Mar 22, 2005 12:07 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 7:37 am 
Offline
PostWhorePornStar
User avatar

Joined: Fri Jan 17, 2003 5:00 pm
Posts: 7672
Location: Tallahassee, FL
I forgot to mention I like the Rocky & Bullwinklesque title to this little debate.


Now, I agree with you, you aren't being fair. :P

The thing is, that Haskell may be a bit shorter, but I need to know, which in the end would be smaller and run faster?

I don't really know, and I need someone who does.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 8:07 am 
Offline
Addict
User avatar

Joined: Fri Nov 08, 2002 5:00 pm
Posts: 4439
Location: You can't take the sky from me. Since I found Serenity.
They would probably be about the same speed.

I'll guess that C++ will edge it out on the speed. But I've never actually used Haskell.

Then again 9/10ths of that stuff is second nature to a C++ programmer, who more than likely can write that without thinking. So I wouldn't think that dev time would suffer much in this case, but training time would in general between a lisp style language and C++.

All in all I'd still stick with the procedural language. I personally find it easier to conceive complicated tasks with.

Lisp variety languages tend to get wordy when you have to initialize data and perform several different operations on several variables.

_________________
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 12:30 pm 
Offline
Native
User avatar

Joined: Wed Dec 11, 2002 5:00 pm
Posts: 869
Depending upon the compiler, the C++ program will be about twice as fast as the Haskell program. I say this because the C++ compiler has to optimise away the le parameter functional when the type T already has a primitive less-than-or-equal operation on it, such as when T is int. Haskell compilers already know how to do that, but it's very hard for a C++ compiler. Furthermore, Haskell itself is one of the slower compiled functional languages; the equivalent program in SML or Concurrent Clean will be almost as fast as the C++ program.

Now, yes, the particular algorithm I chose for a first example was pretty simple in any language. (Well, as long as that language supports recursion. Fortran 77 does not. Don't sort things in Fortran 77. In that vein, all you scientific programmers, upgrade to Fortran 90, please! Please!) The strength of the higher-level language approach is the ease of the expression of an algorithm. For example, in C++, I can actually get a bit of speed-up in the Quicksort algorithm above by declaring it inline; now, naturally, as Quicksort is a recursive algorithm, it can't be entirely in-lined, but a good C++ compiler will in-line the first few recursive calls, and a really good C++ compiler (there aren't any, but G++ is close) will notice that the second recursive call is a tail call and optimise that. In C, it would be necessary to do the in-lining by hand, and it would make the program terribly messy and terribly hard to maintain.

Messy is bad.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 3:00 pm 
Offline
PostWhorePornStar
User avatar

Joined: Fri Jan 17, 2003 5:00 pm
Posts: 7672
Location: Tallahassee, FL
But this isn't a battle about C. Its about C++.

I'm a prick.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 4:12 pm 
Offline
Native
User avatar

Joined: Wed Dec 11, 2002 5:00 pm
Posts: 869
C++ is very, very messy. Spot the error:

Code:
template <class T> struct cart {
    typedef T t;
    t x;
};


Hint: it's missing a keyword, and that keyword was added during standardisation.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 6:48 pm 
Offline
Expatriate
User avatar

Joined: Fri Oct 15, 2004 9:44 pm
Posts: 134
Location: Screaming obsenities regarding untestable C++ software.
^^ My employers have a very simple solution to that exact problem. I'll bend the rules a little and quote our internal documentation.

C/C++ Standard Requirement #104: Don't use templates.

C++ can be evil in the wrong hands. ;)

_________________
"Their need for total domination and to bring the world to the edge of utter apocalypse makes them less-than-ideal Jenga partners."


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 23, 2005 3:39 am 
Offline
Native
User avatar

Joined: Wed Dec 11, 2002 5:00 pm
Posts: 869
Ylis wrote:
C/C++ Standard Requirement #104: Don't use templates.


I can definitely understand the rule, but I myself would disagree with it strongly. The best reason to use C++ is to use templates -- i.e. strongly-typed ad-hoc genericity, and the facility of template metaprogramming if it becomes appropriate. Indeed, without templates, we can't even use the standard C++ library, because (for example) even std::istream is a template instantiation. Do you like the <vector>, <algorithm> and <functional> class libraries? Well, you can't have them. And so on.

It's just that templates in particular as a means to provide ad-hoc genericity are so ill-conceived. Compare, for example, Java 1.5 generics to templates. Java has needed a facility for generic programming for a long time, and now it has one; and, because Sun can look at C++ and see all kinds of bad things going on with templates, they did it better.

Without type genericity, it becomes impractical in a a statically-typed language like C++ to implement algorithms and data structures that are blind to types. For example, consider the algorithm std::swap():

Code:
namespace std {
    template <class T>
    inline void swap(T& a, T& b) { T t = a; a = b; b = t; }
}


Swapping two values of type T is done the same way whatever T happens to be. Writing a swap function (or a sort function, or a multimap ADT) for every possible type T is painful and bug-prone, and perhaps counterproductive in other ways, too.

Example 1: the standard C++ std::sort() algorithm is orders of magnitude faster than the standard C qsort() function. The reason for this is that the comparisons made by the quicksort algorithm are inlined by the compiler, not represented as a function that the program must call. Furthermore, the signature of qsort is (I think)

Code:
extern "C" void qsort(void *, size_t, size_t, int (*)(const void *, const void *))


thus since it must be able to sort arrays of anything at all, it is naturally completely type-unsafe. std::sort() has no such problem.

Example 2: the standard C++ std::multimap (and variants std::map, std::multiset, and std::set) are implemented most often as red-black trees. The original SGI library used a red-black tree, and any compiler vendor that licenses the SGI library copies the algorithm. Map and multiset are implemented in terms of multimap, and set is implemented in terms of multiset. Red-black trees are very finicky to write. I would much prefer to trust the implementor of my language's library to do it and do it right once than to do it myself every time I need a dictionary structure in my program.

Counterexample 2.5: The Standard C++ committee forgot to include a hash_multimap in the standard C++ library. It's a significant oversight. Lots of helpful programmers have written their own versions of this ADT and made them available to us; naturally, they don't work well with each other even if they work well all alone.

Example 3: The Boost libraries are really useful, and make heavy use of templates and template metaprogramming.

However.

In that C++ has generics, it's hardly alone; lots of other languages do also. Ada has generics. Eiffel has generics. Even Java now has generics. Every statically-typed functional language has generics. Lisp is a dynamically-typed language, and so doesn't need them; nevertheless, any Lisps actually do have a sort of generic facility in what is called "macros" in Lisp, but those macros are nothing like the macros we know from software like C or vi.

By the way, the answer to the problem I posed:

Code:
template <class T> struct cart {
    typedef typename T t;
    t x;
};


Because of one of C++'s ugliest misfeatures ("if it looks like a declaration, it is a declaration") C++ can't tell that the T in the typedef is the same as the T in the parameter in the template. It needs the typename keyword to make that connection.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 07, 2005 7:30 pm 
Offline
Expatriate
User avatar

Joined: Wed Nov 13, 2002 5:00 pm
Posts: 86
Location: Canton, Oh, Usa
Programmers hate me...

I write HTML, and i HATE it when people write Messy HTML code. I also have this nack of finding all the small errors. So this one guy would write a huge website, have error here and there, spend 5 hours on it. I would sit down, clean up the code, find the errors in about 1 hour, if not less...

Coders do not like there code messed with by someone else ;-)

Anyway im not a programer, im a IT tech guy who can tear apart a computer and put it back togeather...

My question How hard is machine code to learn? I never looked too deeply into it but really, how hard is it?

_________________
By my hand and seal, Talauna


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 07, 2005 7:56 pm 
Offline
PostWhorePornStar
User avatar

Joined: Fri Jan 17, 2003 5:00 pm
Posts: 7672
Location: Tallahassee, FL
If you've never coded before, its going to be 100% polynesian.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 52 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 27 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group