Well the simple fact is advertising executives have MUCH more experience than you in ascertaining the play-off between annoying/distracting and revenue clicks. And I guess your gut feeling loses out to their terabytes of data.
Well, well, well... Of course, you make assumptions about my experience. Yet you know me not.
I spent about 3 or 4 years doing Internet Marketing. I think I know a thing or two about what will grab attention and what won't. About what clicks will actually lead to sales and what will just be curiosity seekers that will eat up your click-thrus and not buy anything.
Many advetisers get it all wrong -- they spend enormous efforts at generating click-thrus but not refining their techniques so that they only get the clicks that lead to purchases. Their money to waste, and I am more than happy to take their money when they advertise on my sites.
On the other hand, myself personally will ignore most ads and wish that the advetiser could actually figure out what I'd really be interested in, because I would love to see the very thing that I "just gotta have no matter what."
What we really need is better targeting technology. The current stuff all depends on word matches that becomes rather elusive. Semantic matches that can match the actual content (not the words in the content) to a product or service that the content consumer would actually want to buy would be sweeter than sweet, and would cut down on much of the annoyance.
There are other approaches that I can think of or know, but I am not going to write a book in this post.
Facecrook, Google et al. use the same idea: be the middle man, make the user come to you as the first thing when they need to contact someone, or want some information, etc..
Shouldn't we be putting all those middlemen on the B Ark?
I couldn't agree more. Stupid users are the worst nightmare for for a sys admin. They will always click first before thinking, which opens the door to all sorts of exploits that stupid users will far for.
So the most secure thing in this regard is to block all ads, and also check for sites that have been blacklisted. Firefox is good in that regard. Can't speak about the other browsers.
And I should be easy on "stupid users" -- we are talking basic human nature and natural curiosity, coupled with ignorance of the technical ramifications of making some of those clicks. And anyone can fall prey to the "stupid user" syndrome, especially if you have just woken up and not had your coffee yet!!!!
I think Flash ads are notoriously evil. They do chew up your computer resources big time. Not to mention some are so obnoxious as to play sounds out of the blue. Really annoying when you are not expecting it, or are listening to music.
Some of the worst of this lot I've seen on The Pirate Bay, so maybe I should try AdBlock for that site. Normally I don't mind ads that behave themselves and don't try to "get in your face". But Flash ads have gone too far afield in this regard.
Let's face it. If you have something to advertise that I am interested in buying, a simple JPeg ad will get my attention. If I am not interested, the most flashy of Flash ads will have no hope in hell of changing my mind, and become annoying if they start tying up my computer resources trying to get my attention for their crappy products.
The owners of Escapist and other sites should recognize this basic fact and spend more time policing the ads and less time harassing their users, who can go elsewhere in a heartbeat. I thought this was obvious, but some never learn.
And when your browser chews up 400 megabytes or worse due to these bloaty ads, that's a problem. Users shouldn't have to throw out their old computers and buy the latest and the greatest just so they aren't slowed to a crawl -- or even crash -- because of silly bloaty ads. Go figure. So the STFU works both ways.
But interpreted does not imply scripting. I would say that a script is a collection of command line bits and pieces with some logic to glue it all together. Consider that in bash, you would have "rm/logs/x" on a line by itself but in Perl, you would have to system() [or similar] the command.
Please do not teach any lawyers anything about Python. What is left in readability would be destroyed.And they would go on to other languages like Perl, Now that's a lawyers language:D
We will have to make a new language for them call black and white. Where any gray terminology is a syntax error.
Don't even get me started with lawyers and code!!! I have a patent on a GUI interface that I sold to a major networking company which was involved in a patent infringement lawsuit a few years back, and this beautiful Java code that I implemented the software invention in was picked to death by the lawyers during the deposition.
They didn't really understand the code as much, but paid a hell of a lot of attention to the comments, and would bash me on the most uninteresting aspects of what I did. I almost wish I hadn't put any comments in at all.
They did pick on a few functions here and their, but again the most uninteresting aspects. It was quite annoying and it's a wonder why I didn't shoot them for sacrilege.
Oh, I recall why now. They were paying me big bucks per hour for my time. Talk about money without joy!
I tend to wear many hats at wherever I work, and sometimes have to swap between dev and systems (or ops if you prefer). I prefer dev, of course.
I hear you on the name completion on large projects, but I always find properly done documentation to be a better approach -- because name completion doesn't really do much to help you understand what the function is supposed to do.
But, reality as it is, programmers typically hate to document their stuff, so I wind up looking at their source instead. And well, at that point, everything is there in front of me.
And yes I've done large scale development. Others used the fancier IDEs; I used Emacs. Just as productive, if not more so.
vi! You must me more of a systems guy. I'm more of a software dev guy and therefore like Emacs better. I always get tripped up by how to exit from vi -- many utilities like svn automatically drops you in a vi session. Ouch.
A "secure system" that depends on the secrecy of the code for its security is not secure. One should take it as read that the code has been (will be) released to the world. How does one design a secure system with that in mind?
Yes, even the best security code can have design flaws, but a company the size of Google should be able to afford a security audit team to hunt down those very vulnerabilities.
I would prefer using Ruby instead of Perl in that regard -- except, of course, you have the issue of whether or not Ruby is installed, and what version of Ruby is there. Ran into that headache big time with RedHat distros -- they were always 2 or 3 revisions behind what was GA.
You might just consider doing a filename scrub -- renaming the files to something more script-friendly during processing. Or you can create soft links to the filenames riddled with spaces before processing, and just delete the links when you're done. There's a number of ways to skin the "space in the filename" cat issue.
The line between what is a "script" and what is an "application" has been blurred. Ruby, Python, and PHP are all "scripting languages" and yet many, many killer applications are written in them (like Blender, for example!).
Bash scripting definitely has everything you'd need to write an "application" in, but many data constructs would be awkward to implement in Bash, so you'd use Python, Perl, or Ruby.
But what I can do in Bash I could also do in Ruby or Python very easily. What I could do in Ruby or Python would be very difficult to do in Bash.
Then you have Java and C++ which are clearly not scripting languages, but I could do everything there that I could do in Bash. On the other hand, most things interesting you can do with C++ would be next to impossible with Bash. You just can't beat the performance of compiled languages. On the other hand, development would be costlier and portability might be an issue.
Then again, you can tap a thumb tack in with a sledge hammer, but you run the risk of putting a nasty hole in your wall!
It all comes down to what is the right tool for the job. So many tools, though! So pick and choose wisely. But you knew that already.
Personally, I have given up on making a distinction between what is a "scripting language" and what's an application language. Javascript(!) is a "scripting language", but there is a high level of interactivity in the applications it's used for typically. Both in communicating with the server (AJAX) and with the user.
Many of these so-called "scripting languages" allows for object-oriented programming. Bash, of course, does not. But then it was never meant for that level of sophistication. But that's even more blur for you. But you knew that already too.
Yeah, because emacs is the epitome of "lean and stripped down," right?
I've been writing code for about 14 years. For some things, command line, vim, and a quick terminal session are great. For other things, IDEs like Eclipse and Netbeans are absolutely wonderful. Sometimes that multi-view GUI is just right, especially on a bigger (or dual) monitor setup. My usual workflow involves opening half a dozen putty windows to the servers I need to access, and an Eclipse window for the Database, ClearQuest, ClearCase, and perl work I'm touching.
Big & bloaty? Perhaps. But I'm not getting paid to minimize processor & memory usage on my laptop. I'm getting paid to deliver business solutions, and so I choose the toolset that is appropriate to my workflow and my requirements. Your condescension about the command line likely puts off quite a few people you work with - what a shame you'll find yourself relegated to maintaining the equivalent of legacy mainframe code because "that guy knows command line stuff like this, and nobody wants to work on projects with him anyway..."
When you are managing a hundred servers (or more) for a high-profile, high-traffic, high-availability web site, good luck with your GUI tools. Unless they were written *specifically* for that operation, they are NOT going to be a good fit.
I'm not putting down GUI entirely -- as I am all for using the right tool for the job. If you are doing Java apps, Netbeans or Eclipse is probably the best way to go. But Java is not the best choice for everything, and there are many different environments out there. Rare is the luxury of designing the environment from the ground up. Usually, you are thrown into the middle of a failing mess that someone else created. I too got paid to deliver, and deliver I did.
Oh, and my people were very happy to work with me, as well as other departments who always came to me for "all the answers".
Most of the young developers and sys-admins I've been running into lately are completely clueless about the command-line. They expect bloaty web interfaces and resource-consuming IDEs to "hold their hand" and do what they otherwise cannot do.
Back when I was paid to make sure everything would run as long and as smoothly as possible I would craft well written scripts, config files, and documentation. My last employer didn't care about that kind of stuff and wanted things done quickly, so you can be damn sure we used Windows.
Right clicking to add a DNS zone, virtual hosts, or firewall rule is often faster than adding lines to a config file. It may not have the same level of precision, but it's fast.
I wrote web interfaces to do that sort of thing, and it's not only fast, but it's precisely what I needed, done the way I needed at the time.
There are lots of situations where a debugger is no use and only log output is. I wonder what you would do when you found that your standard way of doing things didn't work?
Yeah, like debugging a multithreaded application. Way back when when I was doing that in Java development, I actually found JDB command-line far more useful than the debugger in the big bloaty IDE of the time.
It's all about the right tool for the job. Someone who couldn't handle command-line would be hamstrung by the limitations of the IDE. When I run up against those, I ALWAYS have options around.
A developer, as it a real developer and not some perl dweeb, doesn't touch server admin.
The best C developers I know, are or were admins at one point.
Writing software for servers is a fuckton easier when you actually understand what a server does and what goes on from the admin point of view.
A decent developer that understands administration if FAR better than some hot coder that doesn't have the security insight of a gnat.
You know at those 'BIG' sites you see on the Internet... facebook, wikipedia, myspace, google... guess what... All of their senior level developers... regularly play admin as well to deal with large problems.
I'm going to have to wager that you are a developer with no admin experience and little actual development experience since you don't recognize something thats pretty common.
Wouldn't surprise me, since he thinks I'm just a dumb perl dweeb.
And oh yes, I've dealt with doing database admin for a major social site that saw 60,000 simultaneous users daily. Not exactly the size of Facebook, but definitely way beyond some small-time mom-and-pop operation.
What really helped was having a deep understanding of the OS architecture and of software in general. Understanding WHAT the database does at the low level, like IO to the disk, was *critical* in making that site work and reliable. And it's just not the sort of thing they teach in college, I don't think.
You are confused. One minute you claim long winded text entry for 30 years beat tools designed to replace the drudgy or trivial stuff is better, then you claim you write noddy script to toy server duties. A developer, as it a real developer and not some perl dweeb, doesn't touch server admin. So what is it? I suspect you're a low skilled UNIX package user that's been using packages for your job, but you dabble in code for trainee level work.
IDEs have a place, they can get the cruft out of the way, if you're development time is cheap, you're not a real developer. Get back to your 10 line "scripts".
Really? You are wrong. Very wrong.
My career got kicked off with writing an operating system from scratch back in 1980 when I was 18. Since then, I have done just about everything -- systems development, middleware, and applications. From software architecture to database architecture. Network programming, number crunching stuff, and more to boot.
Do YOU know what a "real developer" is? How many languages you know? Let's see -- do you know C++, C, Java, assembly, Ruby, Python, Forth, Lisp, PHP? Have you ever written a driver, let alone a complete OS? How are you with multithreading? Know the difference between a semaphore and a critical section? Spin locks? Do you know what a coroutine is? First class functions? Can you handle C's pointer arithmetic without bringing the entire system crashing down to its knees?
And you think I'm just a "low-skilled perl dweeb". Right.
I still use Emacs proudly. I find big bloaty IDEs like Eclipse get in the way
Really, the only thing you are saying here is that you like YOUR big, bloaty thing over someone else's big, bloaty thing. There's really nothing insightful about that at all.
You have a set of tools you are comfortable with, and others have theirs. Each have their merits and each have their drawbacks. What is new is not necessarily an improvement and what is old is not necessarily the best. To discard either out of hand on their "whiz-bangedness" or "tried-and-truedness" rather than on its merits is the mark of a fool.
You calling me a fool?:-)
And even though Emacs is "bloaty", it's bloaty by 1980 standards. Not by today's standards.
Having said that, I do like the class browser features of some of the more current IDEs, Something that Emacs could use some improvement on. But I love the overall power Emacs has that the other IDEs never will, such as its keen macro abilities, limitless configurability, small memory footprint by today's standards, and it's wonderful ability to run in a text console as well as a GUI window.
But I don't want to start an IDE RWar. Just ranting, basically. I've used Eclipse, Visual Studio, and a couple of others in the past, and I still think Emacs beats most of them in a number of areas.
When doing Java development, especially when dealing with J2EE, you are probably better off using Eclipse or other IDEs specifically geared to deal with that (over) complexity. But Java is quickly loosing ground to some of the other solutions available.
I always say, use the best tool for the job. But beware if the tool itself becomes a millstone around your neck. I've seen that happen way too many times in the past. Probably the worst of the lot was Microsoft's MFC framework, where you had to go around it every time you wanted to get something useful done. Don't know what.NET is like, nor do I really care too, really. I left Microsoft development for Linux many moons ago and I am not looking back.
I do mixed mode. I do run Gnome, but use it for launching multiple Konsole sessions. Since I am doing web development, I do need to run the big 3 browsers. Etc.
I am not totally adversed to GUI, as I was a GUI developer for many years in the 90's. Writing GUI code is inordinately complex and you still can't get all the functionality that you can from command-line, except, of course, for those applications that are GUI-intensive, like animation and ray tracing. But many have written such engines without a GUI front-end.
I'm just annoyed at those who *only* know GUI, only know one programming language, and have a hard time dealing with basic data structures and can't tell a LIFO from a FIFO. I wrote an operating system when I was 18, back in 1980, and it was a lot of pure fun. It was preemptive multitasking, ran in 64K of RAM, and on the bigger machine it did paging. All that WITHOUT college.
So I may be a bit jaded when I look at today's college grads that only know a couple of high-level languages and would have no clue what an interrupt is. Obviously, that's not always the case, and is definitely not the case with the crowd on/., but it's what I come across all the time when I hunt for candidates.
Hey! I take offense to this. I am a 23 year old IT Guy and I program everything in CL. Embedded systems? Command line. Stupid python based interfaces? Command line. Assembly modules for both of those? Command line. I haven't actually used a monitor on my unix box since I installed it. I just putty in and go from there.. please don't group all of us together. I agree, most new IT guys are frigen in love with there pixel candy.. but some of us(IE the good ones you want on your team) still crack stuff out in black and white. The only time I even look at graphics is when I am building out an interface for my robots control systems on my custom remote(LCD + ARM chip + Xbee transmitter/receiver).
I've been writing code for over 30 years, and there is no way some fresh college grad can come even close. Nope. They may be more up on the latest whiz-bang pattern or "programming methodology", or can work "wonders" with the latest IDEs or what not, but when it comes down to what counts, they are *lost*.
I still use Emacs and the command-line proudly. I find big bloaty IDEs like Eclipse get in the way and demand a lot of attention to themselves, taking away from the development process. And why? Just so I can get some silly name-completion? BFD. If you know the code, the name-completion crap won't really add much to your productivity.
I can (and do) configure web servers from command-line all the time. I create wonderful scripts that do specific routine tasks for me. And you know what? It works. It's lightweight. And easy for me to maintain. And document for someone else to use.
Most of the young developers and sys-admins I've been running into lately are completely clueless about the command-line. They expect bloaty web interfaces and resource-consuming IDEs to "hold their hand" and do what they otherwise cannot do.
Looking at the stats graph on the website listed in the article, I did not see a corresponding ownership distribution stat among the different age groups. Without knowing the ownership distribution, the "skewed" incident stats we see are close to useless.
I'm not willing to guess about the ownership distribution among the class of cars seen to have this acceleration problem. As usual, reporters fall down on the details.
Toyota may be off the hook, but we still can't know for sure.
Slashdot Mirror
Well the simple fact is advertising executives have MUCH more experience than you in ascertaining the play-off between annoying/distracting and revenue clicks. And I guess your gut feeling loses out to their terabytes of data.
Well, well, well... Of course, you make assumptions about my experience. Yet you know me not. I spent about 3 or 4 years doing Internet Marketing. I think I know a thing or two about what will grab attention and what won't. About what clicks will actually lead to sales and what will just be curiosity seekers that will eat up your click-thrus and not buy anything.
Many advetisers get it all wrong -- they spend enormous efforts at generating click-thrus but not refining their techniques so that they only get the clicks that lead to purchases. Their money to waste, and I am more than happy to take their money when they advertise on my sites.
On the other hand, myself personally will ignore most ads and wish that the advetiser could actually figure out what I'd really be interested in, because I would love to see the very thing that I "just gotta have no matter what."
What we really need is better targeting technology. The current stuff all depends on word matches that becomes rather elusive. Semantic matches that can match the actual content (not the words in the content) to a product or service that the content consumer would actually want to buy would be sweeter than sweet, and would cut down on much of the annoyance.
There are other approaches that I can think of or know, but I am not going to write a book in this post.
Facecrook, Google et al. use the same idea: be the middle man, make the user come to you as the first thing when they need to contact someone, or want some information, etc..
Shouldn't we be putting all those middlemen on the B Ark?
So the most secure thing in this regard is to block all ads, and also check for sites that have been blacklisted. Firefox is good in that regard. Can't speak about the other browsers.
And I should be easy on "stupid users" -- we are talking basic human nature and natural curiosity, coupled with ignorance of the technical ramifications of making some of those clicks. And anyone can fall prey to the "stupid user" syndrome, especially if you have just woken up and not had your coffee yet!!!!
Some of the worst of this lot I've seen on The Pirate Bay, so maybe I should try AdBlock for that site. Normally I don't mind ads that behave themselves and don't try to "get in your face". But Flash ads have gone too far afield in this regard.
Let's face it. If you have something to advertise that I am interested in buying, a simple JPeg ad will get my attention. If I am not interested, the most flashy of Flash ads will have no hope in hell of changing my mind, and become annoying if they start tying up my computer resources trying to get my attention for their crappy products.
The owners of Escapist and other sites should recognize this basic fact and spend more time policing the ads and less time harassing their users, who can go elsewhere in a heartbeat. I thought this was obvious, but some never learn.
And when your browser chews up 400 megabytes or worse due to these bloaty ads, that's a problem. Users shouldn't have to throw out their old computers and buy the latest and the greatest just so they aren't slowed to a crawl -- or even crash -- because of silly bloaty ads. Go figure. So the STFU works both ways.
Yeah, the core is written in C. I gaffed on that.
many killer applications are written in them (like Blender, for example!).
I think, not really sure, that Blender is written in C and only the scripting part uses python.
You are correct. I stand corrected. http://urlbit.us/ihd
But interpreted does not imply scripting. I would say that a script is a collection of command line bits and pieces with some logic to glue it all together. Consider that in bash, you would have "rm /logs/x" on a line by itself but in Perl, you would have to system() [or similar] the command.
Ah, see! Blurrier yet!
Please do not teach any lawyers anything about Python. What is left in readability would be destroyed.And they would go on to other languages like Perl, Now that's a lawyers language :D
We will have to make a new language for them call black and white. Where any gray terminology is a syntax error.
Don't even get me started with lawyers and code!!! I have a patent on a GUI interface that I sold to a major networking company which was involved in a patent infringement lawsuit a few years back, and this beautiful Java code that I implemented the software invention in was picked to death by the lawyers during the deposition.
They didn't really understand the code as much, but paid a hell of a lot of attention to the comments, and would bash me on the most uninteresting aspects of what I did. I almost wish I hadn't put any comments in at all.
They did pick on a few functions here and their, but again the most uninteresting aspects. It was quite annoying and it's a wonder why I didn't shoot them for sacrilege.
Oh, I recall why now. They were paying me big bucks per hour for my time. Talk about money without joy!
I hear you on the name completion on large projects, but I always find properly done documentation to be a better approach -- because name completion doesn't really do much to help you understand what the function is supposed to do.
But, reality as it is, programmers typically hate to document their stuff, so I wind up looking at their source instead. And well, at that point, everything is there in front of me.
And yes I've done large scale development. Others used the fancier IDEs; I used Emacs. Just as productive, if not more so.
vi! You must me more of a systems guy. I'm more of a software dev guy and therefore like Emacs better. I always get tripped up by how to exit from vi -- many utilities like svn automatically drops you in a vi session. Ouch.
Yes, even the best security code can have design flaws, but a company the size of Google should be able to afford a security audit team to hunt down those very vulnerabilities.
The fact that Google is paranoid speaks volumes.
Perl definitely has its place, though!
You might just consider doing a filename scrub -- renaming the files to something more script-friendly during processing. Or you can create soft links to the filenames riddled with spaces before processing, and just delete the links when you're done. There's a number of ways to skin the "space in the filename" cat issue.
Bash scripting definitely has everything you'd need to write an "application" in, but many data constructs would be awkward to implement in Bash, so you'd use Python, Perl, or Ruby.
But what I can do in Bash I could also do in Ruby or Python very easily. What I could do in Ruby or Python would be very difficult to do in Bash.
Then you have Java and C++ which are clearly not scripting languages, but I could do everything there that I could do in Bash. On the other hand, most things interesting you can do with C++ would be next to impossible with Bash. You just can't beat the performance of compiled languages. On the other hand, development would be costlier and portability might be an issue.
Then again, you can tap a thumb tack in with a sledge hammer, but you run the risk of putting a nasty hole in your wall!
It all comes down to what is the right tool for the job. So many tools, though! So pick and choose wisely. But you knew that already.
Personally, I have given up on making a distinction between what is a "scripting language" and what's an application language. Javascript(!) is a "scripting language", but there is a high level of interactivity in the applications it's used for typically. Both in communicating with the server (AJAX) and with the user.
Many of these so-called "scripting languages" allows for object-oriented programming. Bash, of course, does not. But then it was never meant for that level of sophistication. But that's even more blur for you. But you knew that already too.
I love Python and I would hate to see it abused this way.
Yeah, because emacs is the epitome of "lean and stripped down," right? I've been writing code for about 14 years. For some things, command line, vim, and a quick terminal session are great. For other things, IDEs like Eclipse and Netbeans are absolutely wonderful. Sometimes that multi-view GUI is just right, especially on a bigger (or dual) monitor setup. My usual workflow involves opening half a dozen putty windows to the servers I need to access, and an Eclipse window for the Database, ClearQuest, ClearCase, and perl work I'm touching. Big & bloaty? Perhaps. But I'm not getting paid to minimize processor & memory usage on my laptop. I'm getting paid to deliver business solutions, and so I choose the toolset that is appropriate to my workflow and my requirements. Your condescension about the command line likely puts off quite a few people you work with - what a shame you'll find yourself relegated to maintaining the equivalent of legacy mainframe code because "that guy knows command line stuff like this, and nobody wants to work on projects with him anyway..."
When you are managing a hundred servers (or more) for a high-profile, high-traffic, high-availability web site, good luck with your GUI tools. Unless they were written *specifically* for that operation, they are NOT going to be a good fit.
I'm not putting down GUI entirely -- as I am all for using the right tool for the job. If you are doing Java apps, Netbeans or Eclipse is probably the best way to go. But Java is not the best choice for everything, and there are many different environments out there. Rare is the luxury of designing the environment from the ground up. Usually, you are thrown into the middle of a failing mess that someone else created. I too got paid to deliver, and deliver I did.
Oh, and my people were very happy to work with me, as well as other departments who always came to me for "all the answers".
Back when I was paid to make sure everything would run as long and as smoothly as possible I would craft well written scripts, config files, and documentation. My last employer didn't care about that kind of stuff and wanted things done quickly, so you can be damn sure we used Windows.
Right clicking to add a DNS zone, virtual hosts, or firewall rule is often faster than adding lines to a config file. It may not have the same level of precision, but it's fast.
I wrote web interfaces to do that sort of thing, and it's not only fast, but it's precisely what I needed, done the way I needed at the time.
There are lots of situations where a debugger is no use and only log output is. I wonder what you would do when you found that your standard way of doing things didn't work?
Yeah, like debugging a multithreaded application. Way back when when I was doing that in Java development, I actually found JDB command-line far more useful than the debugger in the big bloaty IDE of the time.
It's all about the right tool for the job. Someone who couldn't handle command-line would be hamstrung by the limitations of the IDE. When I run up against those, I ALWAYS have options around.
The best C developers I know, are or were admins at one point.
Writing software for servers is a fuckton easier when you actually understand what a server does and what goes on from the admin point of view.
A decent developer that understands administration if FAR better than some hot coder that doesn't have the security insight of a gnat.
You know at those 'BIG' sites you see on the Internet ... facebook, wikipedia, myspace, google ... guess what ... All of their senior level developers ... regularly play admin as well to deal with large problems.
I'm going to have to wager that you are a developer with no admin experience and little actual development experience since you don't recognize something thats pretty common.
Wouldn't surprise me, since he thinks I'm just a dumb perl dweeb.
And oh yes, I've dealt with doing database admin for a major social site that saw 60,000 simultaneous users daily. Not exactly the size of Facebook, but definitely way beyond some small-time mom-and-pop operation.
What really helped was having a deep understanding of the OS architecture and of software in general. Understanding WHAT the database does at the low level, like IO to the disk, was *critical* in making that site work and reliable. And it's just not the sort of thing they teach in college, I don't think.
You are confused. One minute you claim long winded text entry for 30 years beat tools designed to replace the drudgy or trivial stuff is better, then you claim you write noddy script to toy server duties. A developer, as it a real developer and not some perl dweeb, doesn't touch server admin. So what is it? I suspect you're a low skilled UNIX package user that's been using packages for your job, but you dabble in code for trainee level work.
IDEs have a place, they can get the cruft out of the way, if you're development time is cheap, you're not a real developer. Get back to your 10 line "scripts".
Really? You are wrong. Very wrong.
My career got kicked off with writing an operating system from scratch back in 1980 when I was 18. Since then, I have done just about everything -- systems development, middleware, and applications. From software architecture to database architecture. Network programming, number crunching stuff, and more to boot.
Do YOU know what a "real developer" is? How many languages you know? Let's see -- do you know C++, C, Java, assembly, Ruby, Python, Forth, Lisp, PHP? Have you ever written a driver, let alone a complete OS? How are you with multithreading? Know the difference between a semaphore and a critical section? Spin locks? Do you know what a coroutine is? First class functions? Can you handle C's pointer arithmetic without bringing the entire system crashing down to its knees?
And you think I'm just a "low-skilled perl dweeb". Right.
I still use Emacs proudly. I find big bloaty IDEs like Eclipse get in the way
Really, the only thing you are saying here is that you like YOUR big, bloaty thing over someone else's big, bloaty thing. There's really nothing insightful about that at all.
You have a set of tools you are comfortable with, and others have theirs. Each have their merits and each have their drawbacks. What is new is not necessarily an improvement and what is old is not necessarily the best. To discard either out of hand on their "whiz-bangedness" or "tried-and-truedness" rather than on its merits is the mark of a fool.
You calling me a fool? :-)
And even though Emacs is "bloaty", it's bloaty by 1980 standards. Not by today's standards.
Having said that, I do like the class browser features of some of the more current IDEs, Something that Emacs could use some improvement on. But I love the overall power Emacs has that the other IDEs never will, such as its keen macro abilities, limitless configurability, small memory footprint by today's standards, and it's wonderful ability to run in a text console as well as a GUI window.
But I don't want to start an IDE RWar. Just ranting, basically. I've used Eclipse, Visual Studio, and a couple of others in the past, and I still think Emacs beats most of them in a number of areas.
When doing Java development, especially when dealing with J2EE, you are probably better off using Eclipse or other IDEs specifically geared to deal with that (over) complexity. But Java is quickly loosing ground to some of the other solutions available.
I always say, use the best tool for the job. But beware if the tool itself becomes a millstone around your neck. I've seen that happen way too many times in the past. Probably the worst of the lot was Microsoft's MFC framework, where you had to go around it every time you wanted to get something useful done. Don't know what .NET is like, nor do I really care too, really. I left Microsoft development for Linux many moons ago and I am not looking back.
I am not totally adversed to GUI, as I was a GUI developer for many years in the 90's. Writing GUI code is inordinately complex and you still can't get all the functionality that you can from command-line, except, of course, for those applications that are GUI-intensive, like animation and ray tracing. But many have written such engines without a GUI front-end.
I'm just annoyed at those who *only* know GUI, only know one programming language, and have a hard time dealing with basic data structures and can't tell a LIFO from a FIFO. I wrote an operating system when I was 18, back in 1980, and it was a lot of pure fun. It was preemptive multitasking, ran in 64K of RAM, and on the bigger machine it did paging. All that WITHOUT college.
So I may be a bit jaded when I look at today's college grads that only know a couple of high-level languages and would have no clue what an interrupt is. Obviously, that's not always the case, and is definitely not the case with the crowd on /., but it's what I come across all the time when I hunt for candidates.
Hey! I take offense to this. I am a 23 year old IT Guy and I program everything in CL. Embedded systems? Command line. Stupid python based interfaces? Command line. Assembly modules for both of those? Command line. I haven't actually used a monitor on my unix box since I installed it. I just putty in and go from there.. please don't group all of us together. I agree, most new IT guys are frigen in love with there pixel candy.. but some of us(IE the good ones you want on your team) still crack stuff out in black and white. The only time I even look at graphics is when I am building out an interface for my robots control systems on my custom remote(LCD + ARM chip + Xbee transmitter/receiver).
That's cool to hear. I want you on my team!
I still use Emacs and the command-line proudly. I find big bloaty IDEs like Eclipse get in the way and demand a lot of attention to themselves, taking away from the development process. And why? Just so I can get some silly name-completion? BFD. If you know the code, the name-completion crap won't really add much to your productivity.
I can (and do) configure web servers from command-line all the time. I create wonderful scripts that do specific routine tasks for me. And you know what? It works. It's lightweight. And easy for me to maintain. And document for someone else to use.
Most of the young developers and sys-admins I've been running into lately are completely clueless about the command-line. They expect bloaty web interfaces and resource-consuming IDEs to "hold their hand" and do what they otherwise cannot do.
What a waste. And what a loss.
Looking at the stats graph on the website listed in the article, I did not see a corresponding ownership distribution stat among the different age groups. Without knowing the ownership distribution, the "skewed" incident stats we see are close to useless.
I'm not willing to guess about the ownership distribution among the class of cars seen to have this acceleration problem. As usual, reporters fall down on the details.
Toyota may be off the hook, but we still can't know for sure.