Posted - January 13, 2011
Marked Dead - April 22, 2011
Today - Aug 5, 2014
Posted - January 13, 2011
Marked Dead - April 22, 2011
Today - Aug 5, 2014
Yeah, being eVIl, they probably use Vi.
That's still partially rubbish, because you don't build technology on top of a fax machine. Many of the technologies at the higher level are directly written in C, and its going to be a while before the C goes away.
I.e.: its like a world where all our cellphones/email still, under the covers, run over fax, and we still need a fax machine in every house to make this possible. =P
Without people to write the languages in C, and without people to hack on the kernel in C, there will be no more languages, and existing C based languages will get no more features.
The best you can do now is write one high-level language in another, and that tends to be reasonably slow.
Just because you don't understand something, or because you don't know anybody who does, that doesn't mean that technology is disappearing, it just means you're in a selective circle.
Without a testing infrastructure, you pretty much rely on programmers having code doing what they say it does, instead of having proof it does what they say it does.
Given human penchant to slip up and not realise problems until after they are encountered, having tests makes pretty much the difference between "science" and "hypothesis"
It depends which graphs you look at:
These graphs tell me
1. Perl is slightly faster. 2. Perl uses much less memory on average 3. Perl uses less code.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
However, on Ruby18 you do have a substantially bigger problem:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
Lies, Damned lies.
Probably a good reason to use Perl too, finding a machine without it is hard. =)
Because sometimes objects are the right answer, and when they are the right answer, you want to be maximally equipped to use them as easy as possible.
Perl doesn't bash you over the head and make you use objects by making "int" an object, but they're there if you need them.
( And if you really need to, you can make int at least look like an object )
Tests. Integrated Bug Tracking. There's 2 reasons.
You haven't really started using Ruby till you start trying to JAPH and golf it. Fortunately, that phase will pass and you'll return to writing maintainable code =).
>> "The idea of making tools that are joyful to use to the programmers ... basically due to it's syntax."
Thats pretty much entirely "who is working in this language" based imo. As for syntax being a limitation, its interesting you complain that, because others have complained that the syntax is too dynamic, too augmentable, and too unpredictable, hence people talking stuff about it being impossible to write a parser for it =).
Granted, often when this feature is used, its often abused, and there are various 'source filters' in Acme:: you'd get shot if you tried using them in production ( Switch.pm is one such shootable offsense ... with great power comes ... extra unwanted side effects ).
But an example of a Good use of the source filter/metaprogramming nature intrinsic to Perl is MooseX::Declare ( its only part source filter, but its "Sane" because its smart enough to not cause too many unwanted side effects ) to provide alternative class declaration syntax, that some would claim, even looks readable!.
use 5.010;
use MooseX::Declare;
class Foo {
method hello( $what ){
say "Hello $what";
}
}
Foo->new()->hello("World"); # Hellow World\nNice idea, but what tends to happen is this:
-- User1235 has joined #perl --
user1235> PERL SUCKS 111!!!11!!1!!11!!
-- Chanserv set mode +o mst --
-- user1235 was kicked ( troll ) --
The people who are honestly interested tend not to need the door shown to them, and people who aren't interested can't be convinced by such tactics.Protip: you'll get more people interested in you if you spell it Perl instead of PERL. Despite appearances, 'Perl' is not an acronym, there are backronyms for it, but that doesn't mean its an acronym.
I say this only because you give the illusion of knowing something about what you are talking about, and its merely sad to me that you can use Perl for 10 years and never learn this.
( And sadly, not knowing Perl is not an acronym looks bad to people who know different, and thus instantly assume you're not very experienced in Perl )
Pointer Syntax? What? I'm not trying to be an ass here, but I'm confused as how you could have a decade of Perl use up your sleeve and not realise Perl has no pointers. It has references, perhaps, and perhaps I'm just being a semantic pedant, but they're quite different to me.
Then again, I actually find C/C++ pointer tracking and memory allocation daunting, so perhaps that is why I find Perl references more intuitive than not?
In my estimation you can make Perl harder to work with if you try, but you can also make it easier. ie: regular expressions are easier to work with if you use the /x modifier so you can whitespace fill it and document the regex itself, you can do things the hard way with objects, or you can use something like CPAN and get a module that makes this easy ( Moose is my favourite ).
Sure, Perl is perhaps hard for people, I'll give you that, but it doesn't have to be.
If you'd only seen PHP a few times, applying for a job in it may not be the brightest idea. ( If you have enough experience you could probably do a reasonably good bluff and learn-as-you-go, but not recommended ).
I'd suggest something like rating your experience with various things, either by giving it a points/stars rating system, or by having categories such as "Proficient In:" and "Some Experience with:" and "Have also used:" , possibly with examples of where and how you used it.
Hey, wasn't that the year the economy started to go south? .... Obviously, people stopped employing people in Perl, and the economy took a steep dive because of it!. Use Perl! Save the economy!.
( nb. for people with no sense of humour, this was a stab at people who don't understand that correlation != causation )
I see limited use for a digital toaster, there are some perks you /could/ see like having personalized settings which somehow just know which person is using them ( RFID? ) and sets the appropriate toast setting for that person.
Possibly detection on what it is toasting ( ie: hash-browns, muffin-splits ) and "smarter" toasting ( ie: using an optical sensor to measure surface browning, and using a laser thermometer to measure core temperature ( which is required for hash browns because they're often still cold in the middle :( ) ), but these are all purely practical features and I'd want the toaster still 100% practical with no knowledge of these features.
But I'm guessing these sorts of features are not the ones they implement, and probably add silly things like an LCD screen with a countdown timer, and a blingy screensaver, and a robotic toast loader ( ok, on the other side I can see how that would be useful, I do get annoyed every time the toaster is a little too eager and throws my toast in the air and into the sink ..... ) , and they probably add useless features like bread-decorating toasting with high powered lasers or something equally stupid.
Obviously, the VCR your ${parent} keeps asking you to program for them was purchased because it was more complicated, and that silly microwave they have with a big sign on the power socket not to turn it off at the wall, or you'll have to re-set the clock before you can microwave anything, and you need to type in the exact number of minutes and seconds for every single cook time, because you needed to cook for 20 minutes and 7 seconds!
( Sorry, poor and overcomplicated Microwave UI design is one of my Pet Peeves, I don't see many people doing it right, and lots of crap organizations doing it the wrong way yielding horrible nightmare contraptions even intelligent people can't get to do anything practical because somebody lost the manual at some stage )
ALL Hail the indestructible clone phone.
http://www.envirofone.com/Nokia/3315/details.aspx
I owned 2 of these, but sadly, both died the same way.. weird software error "CONTACT SERVICE" and failed to respond to any input. Which is sad, because one of those 2 survived a baptism in uric acid!
Generally, when somebody says "Hi", my reaction is "Oh dear, here comes the dumb question" and I cringe.
9/10 Times I'm right.
Generally I tend to /join and then just sit there for a while to discover the norms and protocols of the channel before speaking, unless I have a specific question/problem.
If I have a specific question/problem then "Just ask" is the best approach, but sadly, 9/10 times I end up fixing the problem myself, and get roped in to help solve 10 other peoples problems while I'm there!.
There's a rare occasion when you'll /join a channel and they'll greet you, but thats part of the 'norms and protocols of the channel' thing, and its usually a hallmark of a small channel, because having 500 users who come and go, if every one said 'hi' , or we greeted each and every one, $topic would never get discussed, and we'd be a 24/7 meet-and-greet channel!
Multiplexing is multiplexing. That is, encoding multiple data streams across one channel. In our case, thats having a singular SSH connection from a to b, but having multiple streams of bidirectional data flowing across that singular connection. https://secure.wikimedia.org/wikipedia/en/wiki/Multiplexing So no, multiplexing is started on the client side, and then it happens on server side too. There has to be a multiplex ( many to 1 ) and demultiplex ( 1 to many ) in order for "multiplexing" to occur.
How did I manage to be such an idiot last year?, and how can I not be such an idiot this year?
It depends. Where do you live? Who are your clients? How complex are the projects? How big is the company? How many other staff are there?
Fortran! Our salvation!.
That's nice. Welcome to the internet.
+1 just for the multiplex magic, But then, I /would/ say that =)
That TTL thing is handy too, I'm sure I had some understanding of it previously, but reading the article made me check my settings and made me realize my timeouts were ridiculously low so even short disconnections killed my session.
The "its easy to get it on a webhost" is one I'll give you, its not really even arguable. Sadly this is one of those annoying chicken-egg issues I try rally against.
Lots of webhosts are really sub-par, and tend to rip off their clients, and much of these same webhosts refuse to give root access, which is a pre-requisite for most of the non-PHP languages.
Sure, PHP will work on these platforms just fine, but as usual, the more people who produce PHP products, the more people out there who'll start dirty nasty webhosts trying to capitalize on that fact, perpetuating the bad hosting situation.
As for personal preferences from a technical standpoint, I'd have hoped somebody like GNU would have had the intuition to develop something well developed like a long-lived FCGI servlet application, which seems to be easy to do in every language except PHP.
PHP seems optimized for the developer use-case where "Something that runs perpetually and handles each request through the system chain" is "Too hard, and Too confusing", and instead they tailor to the 'Every request reloads everything from scratch' style of programming, which is in my personal opinion a design flaw.
Context: I was a PHP programmer for a while. These days I tend to become progressively more and more ashamed of that fact ( except in the obvious case here where I use it to bash it =) ). As a result, I don't frankly care what you use, I like Perl myself these days, but go ahead, use Python or Ruby, both increasingly more common. Heck, use C++ or Java for all I care, there are many decent systems, libraries and web frameworks in those languages ( that is, compared to the pathetic PEAR/PECL + Several dozen frameworks which each and every one of reinvent every wheel twice ), just use one, as long as its NOT PHP.
Just don't do this if you've at some stage backed up another reiserfs filesystem inside your reiserfs filesystem with 'dd'.
the rebuild tree trick mistakenly sees entries in the dd'd copy as being files in the parent file system, and then sprays them all over your drive.
Mostly negative personal experiences.
But that aside, saying "its everywhere" is in my opinion the /poorest/ argument in favor of anything technical.
MySQL has their slogan as being the "Most popular Open Source database", which, by comparison to PostgreSQL's slogan "The most advanced Open Source database", awful.
If you're popular AND good, thats fine, but being popular alone is a poor metric.
I know its trolling to say "Eww, PHP", but every time these days I see yet another project that runs on it, a little part of me dies inside. :(