Yes and no. How's that for a lame answer. Let me expand.
Perl cheats. Take this exerpt, straight from Programming Perl: * An object is simply a referenced thingy that happens to know which class it belongs to. * A class is simply a package that happens to provide methods to deal with objects. * A method is simply a subroutine that expects an object reference as it's first arguement.
What they appear to have done is tack on some features which, when added to your regular old subs in your regular old packages, auto-magically turn the package into a class. Inheritance is barely supported. (There's an array called @ISA which has a list of packages to look in for "methods").
To be honest it seems very kludgy to me. It almost appears as a way for procedural programmers to get that warm and fuzzy object oriented feeling without actually doing it properly. By way of truthfullness in advertising, I'm not terribly familiar with the OO features of Perl, but to my untrained eye, it's somewhat akin to a C programer adding functions to their structs so they've got packaged functions but can still access the data members freely. Sure, you've got an object, but you're missing the point.
As I said above, point taken. I was looking at it from the mindset that you might as well learn everything at once. But looking again, I can see how a learning programmer could get bogged down and frustrated by C++. After all, I learned C first myself* , so what do I know anyway?
In response to your flamebait: You certainly can use C for just about anything you can use C++ for. However there are many extremely useful constructs in C++ for large scale development. Besides, C++ isn't just about OOP. While that is probably the centerpiece of C++, there are lots and lots of extensions which have nothing to do with OOP.
* Actually, I learned Pascal first. Moving from the protective womb-like Pascal environment to the cold and uncaring world of C was scary.:) But once you realize what C can do for you, the payoff is enormous.
Perl zealots sound exactly like VB zealots, and for the same reasons: It's a blunt instrument. It looks "powerful" to them, but that's because they just don't get it.
That is a very insightful statement(ignoring the surrounding flamebait). Gung-ho Perl programmers do have the same mentality and viewpoint as VB programmers. But the reason Perl is so quick is the same reason that VB is so quick. They both let you get away with almost anything. While this is fine for small scripting solutions, it breaks down as your application becomes more complex. Perl is useful, but only for small scripting problems. As your problem grows, Perl becomes less and less useful and no amount of burying your head in the sand will change that.
One of the most important and valuable skills a developer can have is knowing what tools to use for what job. I use Perl to bang out a simple script in a day or two. For anything more complicated I use C or C++.
From a strictly academic viewpoint, Pascal enforces excellent programming practice. Unfortunately, it isn't used very much in the real world. As a general purpose starting language, I'd bite the bullet and learn C++. It has it's own set of ideosyncracies, and you have to be careful not to get too gung-ho on classes (It can be easy to get out of hand, for example, the Microsoft Foundation Classes are just plain scary). Java has some design flaws (see the January and February 2000 issues of C/C++ user's journal) and you are at the mercy of Sun. Plus I don't care what anyone says...Java is slow. With the advent of a standardized C++, it doesn't make much sense to learn straight C right off the bat, and besides, in my experience people who try that end up learning a weird C/C++ hybrid. (ie. the only C++ features they use is streams and the ability to declare variables throughout your code). If you learn C++ though, it is important to learn when not to use it. Sometimes plain old procedural C is best. Hell, sometimes Perl is best. VB is very rarely best, and COBOL is never ever best.:)
For example, in Perl (like most scripting languages) there is a single data type to represent everything from strings to characters to all sorts of numbers. Java/C++/C/Fortran/Basic etc...have different data types (short, long, char, String etc...) for very good reasons.
You make an excellent and very important point. Learning to program with a language as sloppy as perl is probably a BAD idea. Perl is great for banging out a script in a couple days, but I always get this dirty feeling when I declare variables in Perl. If you are writing Perl scripts and don't feel kind of weird about variable declarations and use, you probably should pick up a book like "Code Complete" or maybe "Writing Solid Code". (Yes, they're both Microsoft Press, but that doesn't change the fact that they're excellent books.) Keep in mind that one of the reasons Perl is so quick and easy is because it doesn't enforce much in the way of good programming practice. That makes it great for quick and dirty solutions, but it also makes it easy for a project to collapse under it's own complexity. And I firmly believe that it's very difficult to unlearn bad programming. Remember, the designers of strongly typed languages weren't just being masochistic. Strong typing can save you from yourself.
What you seem to be discribing is "fast" and "powerful", which is all well and good, but it is different from "intuitive". vi is not "intuitive" (yes, I'm a vi junkie). It's extremely fast, but I really don't think you can call an editor "intuitive" when you open it and cannot immediately edit the file by simply typing. Having to type:a to start editing a file is just plain unintuitive.
Not to belabor the point, but here's what Joe newbie should be able to do when using an intuitive editor for the first time: #vi foo.txt type some text to edit the document
What really happens: user: vi foo.txt[enter] vi: ~ user: type vi:.(beep)(beep)clipboard is empty(beep) user: ? vi: ? user: [enter] vi: error user: q vi: (beep) user: x vi: (beep) user: [escape] vi: (beep) user: dsaf (hitting keys at random) vi: f user: fghsdf vi: fghsdf
That's complete nonsense of course but it had the same form. This expanded out to a huge affair in the intermediate code the optimizer uses (one of those embedded functions was inlined(!!)). It was fun. Oh well, I'm sure no one is interested.
First off, fuck you. I don't appreciate being called an idiot.
Second, your oh so great and well thought out opinion has a flaw. Humans are falible. They make mistakes that a compiler will never make.
Third, do I really need to add the disclamer:
Compilers will generate more optimized code (unless a human has 150 years and a huge library)
So lets see...you've insulted me, but that isn't what really pisses me off. You've insulted me and failed to add anything useful to the discussion. We all know that someone can calculate out Pi to the billionth digit using (lots of)paper and pencil. But who cares? They will: A. make a mistake and B. be dead before they finish.
1. Why the hell would you have code like that? It sounds like trying to reuse a variable for two different purposes. Declare two different variables and the compiler will sort it out. 2. Why would you want to use the upper byte for a different value? Unless your working on a weenie chip with only four registers....oh. 3. Byte operations suck on all modern processors I know of...including Pentiums. Congradulations, you've just un-optimized your code. 4. Modern compilers can perform the optimizations you describe, If the optimization is beneficial...which is dubious in this case.
As a side note: I remember hearing FX!32 also keeping some information from the JIT compilation and storing it on disk for the next time the application is run. Anyone knows whether this is still used and to what success?
Yes, FX!32 would actually profile the application and convert parts to native Alpha code, storing the native code in a database. Incidentally, the profiling happened during execution, while the optimization happened during free time, after the program was done being executed. The more you ran the program, and the more code paths you hit, the faster it would get.
It's a moot point now, though, since NT doesn't exist for the Alpha anymore.
This post clarifies what I was saying. To summarize: 1. By "modern processor" I mean a processor that allows a compiler to perform good optimizations. The X86 instruction set is not very good for this. I don't believe the 486 even performed any parallel execution. Specifically, I have experience with the Alpha. 2. You are talking about a specific algorithm. As I said, 99% of the time the compiler will beat you. I didn't say assembly was dead or not useful sometimes. Just that most of the time the compiler will generate faster code overall than a human. 3. Facinatingly enough there are cases where your assembly optimization will actually hinder the compiler from doing a better optimization. Specifically, some paralellizing compilers I think.
Check out this link for a plethora of information on compiler optimizations.
No. Hand coded assembler, coded by a clueful programmer, will always be better than compiler generated code.
You are wrong.
With modern processors, a decent compiler can do better general optimizations than you or any other assembly programmer I've ever heard of. While there is that (less than) 1% of the time when you can hand optimize a small piece of code, that's the exception rather than the rule. The rest of the time you are better off letting the compiler do it's job.
That may be true of a crappy compiler on a lame platform (x86)...but I'd like to see you try reordering and slot scheduling Alpha instructions by hand to enable optimal pipelining and branch prediction. As someone who worked firsthand on a compiler for the Alpha, I can tell you that for 99% of the cases, the compiler can perform better general optimizations than a human. That 1% left over is what you should be concentrating your efforts on. Historically, the point of a CISC processor was to reduce compiler complexity. So of course hand coding optimal X86 assembly isn't going to be difficult.
Do they have every right to edit their broadcasts? Yes.
Do they have every right to edit their broadcasts, then mark them as "live"? Absolutely not.
To the majority of viewers live doesn't just mean "in real time"...live means "in real time and unedited". In fact, taking shows like "Saturday Night Live" as example, Live is more about unedited than about real-time. SNL is delayed by three hours on the west coast.
To put it bluntly, what they did is called lying. It is unethical and if it isn't illegal, it should be.
Exactly. You must remember that marking something as "live" has many more connotations than just "you are seeing this real time". Indeed, many live broadcasts are delayed 3 hours here on the west coast (SNL being a classic example). The only real meaning "live" has in these cases is "unedited". Take that away and live has absolutely no meaning.
traceroute to sarahandcasey.com (209.164.77.91), 30 hops max, 40 byte packets 1 passepartout.web.us.uu.net (208.240.88.1) 0.753 ms 0.515 ms 0.430 ms 2 Serial1-1-1.GW2.DCA1.ALTER.NET (137.39.128.205) 2.017 ms 1.818 ms 1.541 ms 3 105.ATM2-0.XR2.DCA1.ALTER.NET (146.188.161.46) 1.366 ms 2.314 ms 1.921 ms 4 194.ATM1-0.TR2.DCA1.ALTER.NET (146.188.161.146) 1.487 ms 1.856 ms 1.716 ms 5 101.ATM6-0.TR2.CHI4.ALTER.NET (146.188.136.109) 29.039 ms 29.964 ms 30.332 ms 6 298.ATM7-0.XR2.CHI6.ALTER.NET (146.188.209.13) 34.001 ms 31.712 ms 29.723 ms 7 190.ATM8-0-0.GW2.CHI6.ALTER.NET (146.188.208.181) 30.852 ms 31.342 ms 23.331 ms 8 UU-ds3.axxs.net (157.130.101.114) 25.145 ms 24.841 ms 25.663 ms 9 CI-DS3-DFW.PROPAGATION.NET (216.71.87.10) 26.707 ms 25.542 ms 26.414 ms 10 CI-DS3-DFW.PROPAGATION.NET (216.71.87.10) 26.579 ms 26.466 ms 25.267 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * *
I noticed my cihosted domain down at about 2:30 on the 29th. www.cisupport.com's networks status page never even acknowledged a problem. It wasn't until about 9PM that they got a recording on the tech support line explaining some nonsense reason for being down, and projecting restoration in 3 hours. The next day I was pissed enough to wait on hold for a real person. More nonsense. If they had been straight with me, and frequently updated the status, I might have stayed. Not anymore. I'm impressed with Pair.
Redundancy...do everything 50 times. Then call them. Start out polite, but don't be afraid to yell. They are flat out the worst company I've ever dealt with.
Slashdot Mirror
Does Perl support OOP?
Yes and no. How's that for a lame answer. Let me expand.
Perl cheats. Take this exerpt, straight from Programming Perl:
* An object is simply a referenced thingy that happens to know which class it belongs to.
* A class is simply a package that happens to provide methods to deal with objects.
* A method is simply a subroutine that expects an object reference as it's first arguement.
What they appear to have done is tack on some features which, when added to your regular old subs in your regular old packages, auto-magically turn the package into a class. Inheritance is barely supported. (There's an array called @ISA which has a list of packages to look in for "methods").
To be honest it seems very kludgy to me. It almost appears as a way for procedural programmers to get that warm and fuzzy object oriented feeling without actually doing it properly.
By way of truthfullness in advertising, I'm not terribly familiar with the OO features of Perl, but to my untrained eye, it's somewhat akin to a C programer adding functions to their structs so they've got packaged functions but can still access the data members freely. Sure, you've got an object, but you're missing the point.
--GnrcMan--
As I said above, point taken. I was looking at it from the mindset that you might as well learn everything at once. But looking again, I can see how a learning programmer could get bogged down and frustrated by C++. After all, I learned C first myself* , so what do I know anyway?
:) But once you realize what C can do for you, the payoff is enormous.
In response to your flamebait: You certainly can use C for just about anything you can use C++ for. However there are many extremely useful constructs in C++ for large scale development. Besides, C++ isn't just about OOP. While that is probably the centerpiece of C++, there are lots and lots of extensions which have nothing to do with OOP.
* Actually, I learned Pascal first. Moving from the protective womb-like Pascal environment to the cold and uncaring world of C was scary.
--GnrcMan--
Perl zealots sound exactly like VB zealots, and for the same reasons: It's a blunt instrument. It looks "powerful" to them,
but that's because they just don't get it.
That is a very insightful statement(ignoring the surrounding flamebait). Gung-ho Perl programmers do have the same mentality and viewpoint as VB programmers.
But the reason Perl is so quick is the same reason that VB is so quick. They both let you get away with almost anything. While this is fine for small scripting solutions, it breaks down as your application becomes more complex.
Perl is useful, but only for small scripting problems. As your problem grows, Perl becomes less and less useful and no amount of burying your head in the sand will change that.
One of the most important and valuable skills a developer can have is knowing what tools to use for what job. I use Perl to bang out a simple script in a day or two. For anything more complicated I use C or C++.
--GnrcMan--
Point taken, maybe C++ is a bit complex (I didn't take that route, I went Pascal->C->C++.) What do I know, anyway? :)
Casey
--GnrcMan--
From a strictly academic viewpoint, Pascal enforces excellent programming practice. Unfortunately, it isn't used very much in the real world. As a general purpose starting language, I'd bite the bullet and learn C++. It has it's own set of ideosyncracies, and you have to be careful not to get too gung-ho on classes (It can be easy to get out of hand, for example, the Microsoft Foundation Classes are just plain scary). :)
Java has some design flaws (see the January and February 2000 issues of C/C++ user's journal) and you are at the mercy of Sun. Plus I don't care what anyone says...Java is slow.
With the advent of a standardized C++, it doesn't make much sense to learn straight C right off the bat, and besides, in my experience people who try that end up learning a weird C/C++ hybrid. (ie. the only C++ features they use is streams and the ability to declare variables throughout your code).
If you learn C++ though, it is important to learn when not to use it. Sometimes plain old procedural C is best. Hell, sometimes Perl is best. VB is very rarely best, and COBOL is never ever best.
--GnrcMan--
For example, in Perl (like most scripting languages) there is a single data type to represent everything from strings to characters to all sorts of
numbers. Java/C++/C/Fortran/Basic etc...have different data types (short, long, char, String etc...) for very good reasons.
You make an excellent and very important point. Learning to program with a language as sloppy as perl is probably a BAD idea.
Perl is great for banging out a script in a couple days, but I always get this dirty feeling when I declare variables in Perl. If you are writing Perl scripts and don't feel kind of weird about variable declarations and use, you probably should pick up a book like "Code Complete" or maybe "Writing Solid Code". (Yes, they're both Microsoft Press, but that doesn't change the fact that they're excellent books.)
Keep in mind that one of the reasons Perl is so quick and easy is because it doesn't enforce much in the way of good programming practice. That makes it great for quick and dirty solutions, but it also makes it easy for a project to collapse under it's own complexity. And I firmly believe that it's very difficult to unlearn bad programming. Remember, the designers of strongly typed languages weren't just being masochistic. Strong typing can save you from yourself.
And don't get me started on Perl arrays.
(stepping down off soapbox)
--GnrcMan--
The article is all well and good, but it ignores a prime example of a perfect UI designed by hackers, for hackers. Ed.
What's that? You've never heard of it? Don't have access to a Unix box you say?
Fear not! Just compile this source code and you too can experience the joys of ed:
/* ed.c - the editor with the best UI ever! */
#include <stdio.h>
void main()
{
char devnull[80];
while (1)
{
gets(devnull);
printf("?\n");
}
}
--GnrcMan--
When I said: Having to type :a to start editing a file(...)
I of course meant: Having to type a to start editing a file(...)
and when user types: dsaf
the response is actually: (beep)(beep)(...)f
--GnrcMan--
What you seem to be discribing is "fast" and "powerful", which is all well and good, but it is different from "intuitive". vi is not "intuitive" (yes, I'm a vi junkie). It's extremely fast, but I really don't think you can call an editor "intuitive" when you open it and cannot immediately edit the file by simply typing. Having to type :a to start editing a file is just plain unintuitive.
.(beep)(beep)clipboard is empty(beep)
Not to belabor the point, but here's what Joe newbie should be able to do when using an intuitive editor for the first time:
#vi foo.txt
type some text to edit the document
What really happens:
user: vi foo.txt[enter]
vi: ~
user: type
vi:
user: ?
vi: ?
user: [enter]
vi: error
user: q
vi: (beep)
user: x
vi: (beep)
user: [escape]
vi: (beep)
user: dsaf (hitting keys at random)
vi: f
user: fghsdf
vi: fghsdf
You get the point.
--GnrcMan--
Incidentally, the optimizer hint you describe is called "__assume" in Visual C, and it does exactly as you say. So your code would be:
... ... ... // Same as 'notreached'!
switch (x) {
case 0:
case 1:
...
case 23:
default: __assume(0);
}
normally you'd have a define like:
# define ASSERT(e) ( ((e) || assert(__FILE__, __LINE__) )
#else
# define ASSERT(e) ( __assume(e) )
#endif
in order to hide this, but you get the point.
Which brings to mind an optimizer bug that I came across (and fixed) which had to do with a nested turnary operator with two assumes:
__assume(foo() && x==something),bar(&x) ? dosomething() : x == foo ? somethingwierd() : __assume(0);
That's complete nonsense of course but it had the same form. This expanded out to a huge affair in the intermediate code the optimizer uses (one of those embedded functions was inlined(!!)). It was fun. Oh well, I'm sure no one is interested.
--GnrcMan--
First off, fuck you. I don't appreciate being called an idiot.
Second, your oh so great and well thought out opinion has a flaw. Humans are falible. They make mistakes that a compiler will never make.
Third, do I really need to add the disclamer:
Compilers will generate more optimized code (unless a human has 150 years and a huge library)
So lets see...you've insulted me, but that isn't what really pisses me off. You've insulted me and failed to add anything useful to the discussion. We all know that someone can calculate out Pi to the billionth digit using (lots of)paper and pencil. But who cares? They will: A. make a mistake and B. be dead before they finish.
Casey
--GnrcMan--
1. Why the hell would you have code like that? It sounds like trying to reuse a variable for two different purposes. Declare two different variables and the compiler will sort it out.
2. Why would you want to use the upper byte for a different value? Unless your working on a weenie chip with only four registers....oh.
3. Byte operations suck on all modern processors I know of...including Pentiums. Congradulations, you've just un-optimized your code.
4. Modern compilers can perform the optimizations you describe, If the optimization is beneficial...which is dubious in this case.
--GnrcMan--
As a side note: I remember hearing FX!32 also keeping some information from the JIT compilation and storing it on disk for the next time the
application is run. Anyone knows whether this is still used and to what success?
Yes, FX!32 would actually profile the application and convert parts to native Alpha code, storing the native code in a database. Incidentally, the profiling happened during execution, while the optimization happened during free time, after the program was done being executed. The more you ran the program, and the more code paths you hit, the faster it would get.
It's a moot point now, though, since NT doesn't exist for the Alpha anymore.
--GnrcMan--
This post clarifies what I was saying. To summarize: 1. By "modern processor" I mean a processor that allows a compiler to perform good optimizations. The X86 instruction set is not very good for this. I don't believe the 486 even performed any parallel execution. Specifically, I have experience with the Alpha. 2. You are talking about a specific algorithm. As I said, 99% of the time the compiler will beat you. I didn't say assembly was dead or not useful sometimes. Just that most of the time the compiler will generate faster code overall than a human. 3. Facinatingly enough there are cases where your assembly optimization will actually hinder the compiler from doing a better optimization. Specifically, some paralellizing compilers I think.
Check out this link for a plethora of information on compiler optimizations.
--GnrcMan--
No. Hand coded assembler, coded by a clueful programmer, will always be better than compiler generated code.
You are wrong.
With modern processors, a decent compiler can do better general optimizations than you or any other assembly programmer I've ever heard of. While there is that (less than) 1% of the time when you can hand optimize a small piece of code, that's the exception rather than the rule. The rest of the time you are better off letting the compiler do it's job.
--GnrcMan--
The fantasy is that you're some super studly asm c0der who can not only produce properly scheduled code, but al...
Thank you, I couldn't have said it better myself.
--GnrcMan--
That may be true of a crappy compiler on a lame platform (x86)...but I'd like to see you try reordering and slot scheduling Alpha instructions by hand to enable optimal pipelining and branch prediction.
As someone who worked firsthand on a compiler for the Alpha, I can tell you that for 99% of the cases, the compiler can perform better general optimizations than a human. That 1% left over is what you should be concentrating your efforts on.
Historically, the point of a CISC processor was to reduce compiler complexity. So of course hand coding optimal X86 assembly isn't going to be difficult.
--GnrcMan--
My mirror is still here
--GnrcMan--
Do they have every right to edit their broadcasts? Yes.
Do they have every right to edit their broadcasts, then mark them as "live"? Absolutely not.
To the majority of viewers live doesn't just mean "in real time"...live means "in real time and unedited". In fact, taking shows like "Saturday Night Live" as example, Live is more about unedited than about real-time. SNL is delayed by three hours on the west coast.
To put it bluntly, what they did is called lying. It is unethical and if it isn't illegal, it should be.
--GnrcMan--
Exactly. You must remember that marking something as "live" has many more connotations than just "you are seeing this real time". Indeed, many live broadcasts are delayed 3 hours here on the west coast (SNL being a classic example). The only real meaning "live" has in these cases is "unedited". Take that away and live has absolutely no meaning.
--GnrcMan--
It certainly matters to me and tens of thousands of others stuck with no internet presence because of the incompetence of this company.
--GnrcMan--
traceroute to sarahandcasey.com (209.164.77.91), 30 hops max, 40 byte packets
1 passepartout.web.us.uu.net (208.240.88.1) 0.753 ms 0.515 ms 0.430 ms
2 Serial1-1-1.GW2.DCA1.ALTER.NET (137.39.128.205) 2.017 ms 1.818 ms 1.541 ms
3 105.ATM2-0.XR2.DCA1.ALTER.NET (146.188.161.46) 1.366 ms 2.314 ms 1.921 ms
4 194.ATM1-0.TR2.DCA1.ALTER.NET (146.188.161.146) 1.487 ms 1.856 ms 1.716 ms
5 101.ATM6-0.TR2.CHI4.ALTER.NET (146.188.136.109) 29.039 ms 29.964 ms 30.332 ms
6 298.ATM7-0.XR2.CHI6.ALTER.NET (146.188.209.13) 34.001 ms 31.712 ms 29.723 ms
7 190.ATM8-0-0.GW2.CHI6.ALTER.NET (146.188.208.181) 30.852 ms 31.342 ms 23.331 ms
8 UU-ds3.axxs.net (157.130.101.114) 25.145 ms 24.841 ms 25.663 ms
9 CI-DS3-DFW.PROPAGATION.NET (216.71.87.10) 26.707 ms 25.542 ms 26.414 ms
10 CI-DS3-DFW.PROPAGATION.NET (216.71.87.10) 26.579 ms 26.466 ms 25.267 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
--GnrcMan--
By that logic we should be just about to enter the second millennium.
--GnrcMan--
Wow...that is refreshing.
I noticed my cihosted domain down at about 2:30 on the 29th. www.cisupport.com's networks status page never even acknowledged a problem. It wasn't until about 9PM that they got a recording on the tech support line explaining some nonsense reason for being down, and projecting restoration in 3 hours. The next day I was pissed enough to wait on hold for a real person. More nonsense. If they had been straight with me, and frequently updated the status, I might have stayed. Not anymore. I'm impressed with Pair.
--GnrcMan--
Redundancy...do everything 50 times. Then call them. Start out polite, but don't be afraid to yell. They are flat out the worst company I've ever dealt with.
--GnrcMan--