I'm not using Ruby as a synonym for Rails in the last sentence; I'm rhetorically asking why that's a problem for Ruby and not PHP/Python.
I see; I misinterpreted that last sentence (probably tipped off by the ModPython instead of Python). Got it now. My answer to that is still because the framework popularized the language, and they're more frequently discussed in tandem than separately.
Perhaps, but what "PHP" are you comparing with? The language? An ad-hoc index.php with a huge switch() and a function per page? CakePHP? Rails is a big MVC framework, and there's a set of libraries it can use just because it's Ruby. Comparing with "PHP" seems silly because PHP isn't a huge MVC framework. It's like comparing oranges with soil.
God, no! MVC in PHP isn't by having a single page that handles everything. I've written elsewhere (sorry, forget where) of my opinion of PHP Front Controllers... they're stupid, because Apache (or Lighty or whatever you're using) aready acts as a front controller. Models are in library files, Views and Controllers are all individual pages that access the code in those library files, session objects, etc... Views are side-effect-free GET pages, Controllers are POST pages that redirect to other views. There's no in-language framework required, because the overall MVC architecture is already supported by PHP's script-based deployment and HTTP itself. I don't see how that's incomparable with RoR.
Regarding CakePHP... I haven't used it. I don't plan on using it, because it seems to take all of the worst parts of RoR (silly limitations on my database) without any of the best parts (language syntax and power level). But that opinion is probably just a side-effect of my personal preference for data modeling inside the database, where multiple applications can be developed to access the same set of data, instead of relying on a single application's limited data-modeling capabilities. Maybe it's just that all the projects I've worked on have been small enough to not need all the power of ActiveRecord.
My point was that you began the rant referring to Rails, and it just morphed into a referral to Ruby, suggesting that even you (intentionally or not) blurred the lines between the framework and the language. After all, one of the other parents pointed out that ModPython is a library, and PHP itself generally refers to the interpreter plus the standard set of functions available in it, so any conversation about languages will naturally include related tools (including libraries/frameworks). For another example, look at Perl and CPAN, or C++ and the STL (or maybe Boost).
Mind you, I think comparisons between PHP and RoR are perfectly valid in their own right, which is different from most people's opinions. PHP is just much more low-level (which happens to be helpful when it comes to deployment, I suppose).
Ruby is too slow for what I need to do... I know, I know, do more caching do more magic, get more computers, build a server farm, etc.
Or, you could keep your C#, do more caching magic, get more computers, build a server farm, and still win the speed game. Besides, adding an object cache is generally trivial in any language, if you have access to something like memcached, and adding an HTTP cache (sending 304 Not Modified) is as simple as checking a few timestamps.
Stop comparing Rails to languages, you fucking morons... Why is that so difficult to grasp when it comes to Ruby?
Based on your words, it looks like you're having trouble distinguishing between the framework and the language as well. Given that may would-be RoR users have never seen Ruby before, they tend to go together, and thus will always be compared to other languages. That's the price that DHH and his followers have to pay for using a (previously) obscure language to implement a web platform.
If you belong in the field you'll quickly realise that it's stupid to write something that already exists..
...but sometimes there will be a compelling reason to write something very similar to something that already exists. Maybe you can relax the constraints required by the original in order to squeeze out a bit more performance. Maybe you need to handle some edge case differently than the original. Maybe the license of the original prevents you from using it. Heck, maybe you can write an all-around better implementation than the original. It's stupid to write off re-implementation simply to enforce the mantra of code reuse.
I despise makefiles. Java has dependency issues, but they are an order of magnitude less than C/C++.
It's certainly a shame that Makefiles seem to be half of the solution. They have all sorts of built-in rules to make C (and by extension C++) compiling/linking easy, but they don't handle #include dependencies. makedepend is your friend here. In my experience, learning about Makefiles necessitates learning the whole toolchain, be it gcc+gmake+makedepend+ctags+vim or ant+javac+jar+eclipse or devenv+vcproj+vsprops.
I'd rather that Makefiles eschew the implicit rules by default; but beyond that, they're certainly sufficient for any student-sized project.
At most 4 year colleges, even a CS major only really has around 6 compsci classes.
Corollary: At most 4 year colleges, CS majors aren't well-prepared for Computer Science. 6 classes in a subject sounds like a little bit more than a minor. At least I can speak for UIUC—over two thirds of my undergrad hours were spent in CS courses.
...And I guarantee that if we compared the pics between a film camera and a digital SLR, you either wouldn't be able to distinguish between the two, or you'd pick the digital photos as being the better of the bunch. Anyone who's worked in photography will tell you that digital is the only way to go.
Ken Rockwell disagrees. There are certainly still cases where film cameras are superior. DSLRs may be strictly superior for any point-and-shoot use, but that doesn't mean they're "the only way to go".
Ditto for tube amps...
The majority of the brand-name amps are analog, and in the music biz image counts for as much as sound
Indie bands which are just starting out can't afford brand-new equipment, so they end up with stuff that's 15+ years old (hence, analog).
Have you done any guitar amp price-shopping...ever? Bottom-of-the-line tube amps are way more expensive than solid state amps. Assuming that starting bands will use the cheapest equipment available, that would indicate that they will all use solid-state, because it is cheaper.
I guarantee you could get just as good a sound out of digital equipment as you can out of analog, but due to the nature of the music industry there isn't all that much demand for digital equipment. This is changing, of course, as more younger artists enter the business, and more and more technicians become comfortable working with digital equipment.
Tube amps are very complex systems electronically, so they sound different than solid-state amps. They tend to be perceived as more pleasant or "warm" because they distort very nonlinearly without any hard clipping (no "infinite frequency" behavior seen in digital circuitry). From what I hear, Line6 seems to be one of the larger players for guitar amps that simulate analog circuitry with digital circuitry. It's hard to convincingly emulate the analog sound with digital circuitry.
Furthermore, technicians being used to digital equipment really has nothing to do with tube amps. A guitarist can play through a tube amp, and then a technician can record that on a digital mixer into Pro Tools on a computer hard drive. It's not an issue of "out with the old, in with the new". It's an issue of knowing your tools and choosing the one that's most appropriate.
If anyone, with no prior knowledge, was allowed on public roads and highways... don't you think things would be much worse than they are now with licenses?
Sometimes I think I would prefer to be surrounded by people who don't know how to drive right, instead of people who know (or think they do) but don't care. I'd expect a little more caution from the former—and no amount of licensing will prevent the danger presented by the latter.
The entire resume/interview process is designed to be very rewarding for sociopaths, but for normal people just trying to get a job and do something well, it's a minefield where every question has a double meaning, and you're expected to effortlessly rattle off answers to the dumbest questions you've ever heard.
The best programmers and IT workers I've ever met weren't the most charming people in the world. They're overweight, unkempt, and fucking brilliant. They've got personality problems that make them interview very poorly. Nervousness, short attention span, they seem angry or aggressive, "mister literal syndrome", but if you put them in their element, they swim like a shark, they can fix a program to any specification you deliver faster than all the other people you'll interview combined. And they're exactly the people the resume/interview process is designed to weed out.
I really have to disagree with you. Maybe bad interview processes go this way, but here's what I've seen from the last few companies I've looked at:
Chat with HR person to get a feel for personality and overall job goals (filters out expected job surfers or people who really won't fit)
Chat with team member or manager for personality and overall fit
Some sort of tech component. Find out how much skills match the resume. I've seen this include several components:
Online tests like brain bench; these only really tell you if someone is awful, they don't tell you how good someone is.
Small coding assignments to see how someone writes an algorithm... syntax is only a problem if it's obviously wrong (like using a foreach loop in C++ with STL structures, which signifies that the candidate doesn't understand how the iterator concept is actually executed in C++). I don't care if someone remembers the syntax to socket(), read(), select(), a man page will tell you that.
Open-ended software design questions, to see how a candidate approaches problems and how creative they can be on the spot. Not surprisingly, these seem to provide the most information about a candidate.
A candidate that is socially inept, but will "swim like a shark" in a tech interview, will be ok in a situation like this. The only job of HR is to screen through the initial steps here. The problems come when more of the decision-making goes into HR's hands on the technical side. That will only be a problem at very large companies, where there are so many candidates applying that it would overwhelm the team where the opening exists (and in these places, it probably pays off to have a few tech folks dedicated to recruiting). Furthermore, the overall office politics involved in large companies would probably be a big turnoff to the socially awkward geniuses you refer to anyways, so it's a moot point. There are plenty of smaller companies that would be more appropriate and would likely reward true genius much better than a large company, due to the difference of an individual's visibility.
With 9 women you can push them out at a rate of one per month. There's 9 months of latency for the first one though
Ironically enough, this was a topic of conversation with some of my co-workers today. I wonder how frequently software developers end up talking about pipelined pregnancies for optimal baby throughput...
Take for example ConcurrentHashMap (in Java). You really do not need to know how it is implemented to use it efficiently. Or maybe I misunderstood you...
Looking at Sun's doc for that class, it seems you do need to understand at least some of the implementation in order to use it efficiently:
It is a hash implementation, and collisions reduce concurrency.
Retrievals "generally do not block", which means that sometimes they do block. Which means that they may be succeptible to some nasty worst-case-scenarios.
I believe it's fundamental to understand how a container is implemented in order to always use it efficiently (or equivalently, know when it's not appropriate). Most people can use a data structure and have it be the efficient solution 95% of the time, but in order to understand that last 5% you need to know something about the implementation.
I wish someone would develop a language with optional garbage collection and with proper destructors!
Python has both deterministic destruction and garbage collection. Unfortunately, last time I checked, they didn't play together very well. If you had a reference cycle and all of the objects had destructors defined, the GC couldn't break the cycle. But aside from that caveat (which should be easy to address for anyone versed in C++ resource management), it's pretty slick to get the best of both worlds.
WordPress works perfectly under PHP 5. It just happens to also work under PHP 4
Not that this is directly a PHP 4 vs 5 issue, but the tendency that I've seen is that people switching to PHP 5 also tend to be more aggressive about writing "correct code" (maybe because I've mostly seen the early adopters, who are interested in writing code that runs without syntax errors or warnings). I tried running WP about 6 months ago and had to disable E_NOTICE on my server because of all of the crap it spewed out.
WP is standards-compliant, has a lot of plugins for me to play with, and gets updated so much that it's getting a little annoying. Unless any of that changes, I've got no reason to switch.
It also has vulnerabilities discovered fairly regularly (likely due to the loose way it treats data and input), deliberately ignores any database besides MySQL, and (checking...) a simple "about" page fails validator.w3.org with 11 errors using one of the themes provided on wordpress.com Furthermore, the frequent updates are due to the Wordpress guys following a calendar schedule rather than a feature schedule for updates.
I use wordpress.com myself because it just works, but if you pop open the hood it's a big spaghetti mess, and the developers don't seem to care. From an open-source perspective, I'm much more inclined to contribute to a blogging platform that sees value in quality software than WP.
Re:do not stop progress by not wanting 'bloat'...
on
KDE 4.0 RC 1 Released
·
· Score: 1
For all the "bloat" KDE uses less memory and runs faster than Gnome, and we're in the 21st century, so I do expect a fairly fully-featured desktop.
That's why I use KDE on my linux box, instead of Gnome. But I do love the simplicity and raw speed of Fluxbox.
Re:do not stop progress by not wanting 'bloat'...
on
KDE 4.0 RC 1 Released
·
· Score: 1
800mhz Celeron was introduced around Jan 1, 2000. It was a low end chip then designed for inexpensive machines that really didn't even need the power of a "modern" or even laptop. I see no reason that any modern app should consider that machine a supported platform.
While I agree with you that the computer is very old, that kind of attitude is what makes me hate the majority of Web 2.0 apps. I think developers should be using slower-than-average computers and network connections in their dev environments. Too many developers write obscenely inefficient programs simply out of ignorance. I understand that a desktop environment gets more expensive as it starts to do fancier things like complete DBUS/DCOP, automatic device polling, fancy visual cues, etc. But that doesn't mean it's a blanket excuse to write sloppy-slow code or ignore the "maybe-too-slow-but-let's-try-anyways" 5-year old processors.
s for other long duration connections, so far, I have had no trouble using SSH to access my clients' servers for hours at a time. But then, it is a very low bandwidth usage, so Comcast likely doesn't care.
Correct. The network engineers at Comcast doesn't give a hoot what you're downloading. The (il)legality of your network activities don't impact the quality of service other users on the same infrastructure get—just the volume of traffic. If your SSH connection generated gigabytes of data, the story would probably be a bit different.
Lack of memory is not the issue, at least not on a PC.
Lack of memory will always be an issue. No matter how powerful a computer is, there's always an artist who is able to fill all of the available space with realism. There's quite a bit of detail that exists in the world.
Even if you are streaming from a disk, you still need some way of limiting speed, otherwise your dynamic region-loading won't be schedulable... so you really have two limits. No more than X bits of data can "exist" locally at any point in time, and no more than Y bits of data can be "created" per second (streamed from the disk, or procedurally generated, or whatever).
Slashdot Mirror
If that's what you like about playing music (at home, at least), the sound quality difference between an album and an mp3 doesn't matter.
I see; I misinterpreted that last sentence (probably tipped off by the ModPython instead of Python). Got it now. My answer to that is still because the framework popularized the language, and they're more frequently discussed in tandem than separately.
God, no! MVC in PHP isn't by having a single page that handles everything. I've written elsewhere (sorry, forget where) of my opinion of PHP Front Controllers... they're stupid, because Apache (or Lighty or whatever you're using) aready acts as a front controller. Models are in library files, Views and Controllers are all individual pages that access the code in those library files, session objects, etc... Views are side-effect-free GET pages, Controllers are POST pages that redirect to other views. There's no in-language framework required, because the overall MVC architecture is already supported by PHP's script-based deployment and HTTP itself. I don't see how that's incomparable with RoR.
Regarding CakePHP... I haven't used it. I don't plan on using it, because it seems to take all of the worst parts of RoR (silly limitations on my database) without any of the best parts (language syntax and power level). But that opinion is probably just a side-effect of my personal preference for data modeling inside the database, where multiple applications can be developed to access the same set of data, instead of relying on a single application's limited data-modeling capabilities. Maybe it's just that all the projects I've worked on have been small enough to not need all the power of ActiveRecord.
My point was that you began the rant referring to Rails, and it just morphed into a referral to Ruby, suggesting that even you (intentionally or not) blurred the lines between the framework and the language. After all, one of the other parents pointed out that ModPython is a library, and PHP itself generally refers to the interpreter plus the standard set of functions available in it, so any conversation about languages will naturally include related tools (including libraries/frameworks). For another example, look at Perl and CPAN, or C++ and the STL (or maybe Boost).
Mind you, I think comparisons between PHP and RoR are perfectly valid in their own right, which is different from most people's opinions. PHP is just much more low-level (which happens to be helpful when it comes to deployment, I suppose).
Or, you could keep your C#, do more caching magic, get more computers, build a server farm, and still win the speed game. Besides, adding an object cache is generally trivial in any language, if you have access to something like memcached, and adding an HTTP cache (sending 304 Not Modified) is as simple as checking a few timestamps.
Based on your words, it looks like you're having trouble distinguishing between the framework and the language as well. Given that may would-be RoR users have never seen Ruby before, they tend to go together, and thus will always be compared to other languages. That's the price that DHH and his followers have to pay for using a (previously) obscure language to implement a web platform.
It's certainly a shame that Makefiles seem to be half of the solution. They have all sorts of built-in rules to make C (and by extension C++) compiling/linking easy, but they don't handle #include dependencies. makedepend is your friend here. In my experience, learning about Makefiles necessitates learning the whole toolchain, be it gcc+gmake+makedepend+ctags+vim or ant+javac+jar+eclipse or devenv+vcproj+vsprops.
I'd rather that Makefiles eschew the implicit rules by default; but beyond that, they're certainly sufficient for any student-sized project.
I'm waiting to hear from someone whose dad enforced understanding Taylor Series of basic mathematical functions or the common sqrt(x) numerical method before furnishing a calculator. Definitely under the category of "parenting badassery".
Corollary: At most 4 year colleges, CS majors aren't well-prepared for Computer Science. 6 classes in a subject sounds like a little bit more than a minor. At least I can speak for UIUC—over two thirds of my undergrad hours were spent in CS courses.
I prefer Python's list comprehensions (even if they may be less powerful than Lisp... they feel natural):
xlist = [1, 2, -1, 3, -1]
ylist = [ x + 2 for x in xlist if x != -1 ]
Of course, it follows that you should be using better variable names than xlist or ylist...
Ken Rockwell disagrees. There are certainly still cases where film cameras are superior. DSLRs may be strictly superior for any point-and-shoot use, but that doesn't mean they're "the only way to go".
Have you done any guitar amp price-shopping...ever? Bottom-of-the-line tube amps are way more expensive than solid state amps. Assuming that starting bands will use the cheapest equipment available, that would indicate that they will all use solid-state, because it is cheaper.
Tube amps are very complex systems electronically, so they sound different than solid-state amps. They tend to be perceived as more pleasant or "warm" because they distort very nonlinearly without any hard clipping (no "infinite frequency" behavior seen in digital circuitry). From what I hear, Line6 seems to be one of the larger players for guitar amps that simulate analog circuitry with digital circuitry. It's hard to convincingly emulate the analog sound with digital circuitry.
Furthermore, technicians being used to digital equipment really has nothing to do with tube amps. A guitarist can play through a tube amp, and then a technician can record that on a digital mixer into Pro Tools on a computer hard drive. It's not an issue of "out with the old, in with the new". It's an issue of knowing your tools and choosing the one that's most appropriate.
Sometimes I think I would prefer to be surrounded by people who don't know how to drive right, instead of people who know (or think they do) but don't care. I'd expect a little more caution from the former—and no amount of licensing will prevent the danger presented by the latter.
I really have to disagree with you. Maybe bad interview processes go this way, but here's what I've seen from the last few companies I've looked at:
A candidate that is socially inept, but will "swim like a shark" in a tech interview, will be ok in a situation like this. The only job of HR is to screen through the initial steps here. The problems come when more of the decision-making goes into HR's hands on the technical side. That will only be a problem at very large companies, where there are so many candidates applying that it would overwhelm the team where the opening exists (and in these places, it probably pays off to have a few tech folks dedicated to recruiting). Furthermore, the overall office politics involved in large companies would probably be a big turnoff to the socially awkward geniuses you refer to anyways, so it's a moot point. There are plenty of smaller companies that would be more appropriate and would likely reward true genius much better than a large company, due to the difference of an individual's visibility.
Keep up with the standards, man! Acid and death magic are both fortitude saves!
Hey hey, who said anything about opening the book?
Whoa, man. Down with ellipses! Long live paragraphs!
Ironically enough, this was a topic of conversation with some of my co-workers today. I wonder how frequently software developers end up talking about pipelined pregnancies for optimal baby throughput...
Looking at Sun's doc for that class, it seems you do need to understand at least some of the implementation in order to use it efficiently:
I believe it's fundamental to understand how a container is implemented in order to always use it efficiently (or equivalently, know when it's not appropriate). Most people can use a data structure and have it be the efficient solution 95% of the time, but in order to understand that last 5% you need to know something about the implementation.
Python has both deterministic destruction and garbage collection. Unfortunately, last time I checked, they didn't play together very well. If you had a reference cycle and all of the objects had destructors defined, the GC couldn't break the cycle. But aside from that caveat (which should be easy to address for anyone versed in C++ resource management), it's pretty slick to get the best of both worlds.
Not that this is directly a PHP 4 vs 5 issue, but the tendency that I've seen is that people switching to PHP 5 also tend to be more aggressive about writing "correct code" (maybe because I've mostly seen the early adopters, who are interested in writing code that runs without syntax errors or warnings). I tried running WP about 6 months ago and had to disable E_NOTICE on my server because of all of the crap it spewed out.
It also has vulnerabilities discovered fairly regularly (likely due to the loose way it treats data and input), deliberately ignores any database besides MySQL, and (checking...) a simple "about" page fails validator.w3.org with 11 errors using one of the themes provided on wordpress.com Furthermore, the frequent updates are due to the Wordpress guys following a calendar schedule rather than a feature schedule for updates.
I use wordpress.com myself because it just works, but if you pop open the hood it's a big spaghetti mess, and the developers don't seem to care. From an open-source perspective, I'm much more inclined to contribute to a blogging platform that sees value in quality software than WP.
That's why I use KDE on my linux box, instead of Gnome. But I do love the simplicity and raw speed of Fluxbox.
While I agree with you that the computer is very old, that kind of attitude is what makes me hate the majority of Web 2.0 apps. I think developers should be using slower-than-average computers and network connections in their dev environments. Too many developers write obscenely inefficient programs simply out of ignorance. I understand that a desktop environment gets more expensive as it starts to do fancier things like complete DBUS/DCOP, automatic device polling, fancy visual cues, etc. But that doesn't mean it's a blanket excuse to write sloppy-slow code or ignore the "maybe-too-slow-but-let's-try-anyways" 5-year old processors.
Correct. The network engineers at Comcast doesn't give a hoot what you're downloading. The (il)legality of your network activities don't impact the quality of service other users on the same infrastructure get—just the volume of traffic. If your SSH connection generated gigabytes of data, the story would probably be a bit different.
Lack of memory will always be an issue. No matter how powerful a computer is, there's always an artist who is able to fill all of the available space with realism. There's quite a bit of detail that exists in the world.
Even if you are streaming from a disk, you still need some way of limiting speed, otherwise your dynamic region-loading won't be schedulable... so you really have two limits. No more than X bits of data can "exist" locally at any point in time, and no more than Y bits of data can be "created" per second (streamed from the disk, or procedurally generated, or whatever).