Mohtalim

Posted: **Tue Dec 11, 2007 11:11 pm**

Oh why has xkcd betrayed me.

No medicine cabinet sampling for me (yet!)

(I've gotten more than enough comments about that comic from co-workers/friends ~_~)

Posted: **Tue Dec 11, 2007 11:29 pm**

xkcd is a language slut

Posted: **Tue Dec 11, 2007 11:38 pm**

VLSmooth wrote:Oh why has xkcd betrayed me.

No medicine cabinet sampling for me (yet!)

(I've gotten more than enough comments about that comic from co-workers/friends ~_~)

Uh, this is off topic... Anyways, I still mostly use Perl too (and csh). I was thinking of switching to Ruby at some point instead, but I've started playing with Python now too. I think the string handling in Python is a bit nicer than Perl. Part of this stems from the way dynamic typing is a bit less free which allows you to do some type specific operations and in general lets things look more like classes rather than functions that exist in the top level name space.

Posted: **Tue Dec 11, 2007 11:42 pm**

...and then I remembered I'm a mod and could fix the off-topic-ness! Wooo. Feel that power. Nevermind, that was probably just gas from my Coke.

Posted: **Wed Dec 12, 2007 12:13 am**

Yeah, I've been using more python than perl recently. My problem is that I remember all the perl commands easily, but not so much with python. I have to look everything up everytime. Also, I have not found a good editor for python. Notepad works for perl, not so much for python because of the indents.

Posted: **Wed Dec 12, 2007 12:17 am**

You can have my "while(<>){}" when I'm cold and dead.

Posted: **Wed Dec 12, 2007 12:28 am**

Actually, on that note, what type of problems are you using python to fix? I have sort of a hammer-nail situation with the filter design pattern.

Posted: **Wed Dec 12, 2007 1:01 am**

Dwindlehop wrote:You can have my "while(<>){}" when I'm cold and dead.

Just a tip you may already know: perl -pe '<your code here>' automatically wraps the code in with while(<>){}

Posted: **Wed Dec 12, 2007 1:10 am**

Dwindlehop wrote:Actually, on that note, what type of problems are you using python to fix? I have sort of a hammer-nail situation with the filter design pattern.

I think I understand what you mean. Do you have an example?

We have internal perl code that basically performs table operations that you might expect from a database on flat text tables and the ability to pass in arbitrary code to the query filter that operates on every record. We use these as filters all the time to do our work. Why we can't just do this stuff in a database, I have no clue, but this is what we do. It does save on the setup time of doing these sorts of operationss over and over again. The passing in of perl code is nice too. I don't think that python would be all that much better for that kind of munging about of data, but I'm still new to python so I shouldn't judge yet. I think for larger projects, there could be some benefit from using python though since perl can be difficult when dealing with name spaces.

Posted: **Wed Dec 12, 2007 2:16 am**

I like while(<>){}, therefore I approach every problem as something to be solved via while(<>){}. I have a hammer therefore everything appears nail-like.

Edit: Most times I write scripts, I'm automating something tedious. It's either essentially a shell script and I use perl for comfort reasons, generating input/munging output in which case I choose you, filter!, or trying to do something smart.

I'm very happy with my perl filters, but I'm willing to concede that perhaps it's not the right tool for routine automation or doing smart things.

Posted: **Wed Dec 12, 2007 2:23 am**

Fakeedit: most of the time when I design something smart, I decompose the problem into a series of perl filters anyway. Libraries are for suckers.

Posted: **Wed Dec 12, 2007 2:39 am**

quantus wrote:I think for larger projects, there could be some benefit from using python though since perl can be difficult when dealing with name spaces.

I agree with this statement, but in python's defense, it offers a lot more than that.

The biggest benefit python offers is easy object-oriented scripting. Therefore, python is typically better than perl for dealing with increased complexity and maintainability.

However, perl can be extremely fast and easy to code for simple tasks. That's not to say perl doesn't support objects, it's just that the whole bless crap is ugly and a pain in the ass. Regarding perl's maintainability, it highly depends on the developer due to perl's flexible "there's more than one way to do it" (TMTOWTDI) approach, as opposed to python's rigid (draconian?) "there's one correct way to do it". Thank goodness for peer reviews, although the perl expert to perl hacker ratio is still much lower than I'd like. For example, we need more well-written and documented perl modules than code re-writes >_>.

If python was installed on more platforms at work, I'd learn it faster. However, since it isn't, perl is much more useful to me.

Posted: **Wed Dec 12, 2007 3:50 am**

I've used python primarily for string and file processing. I've been using python more than perl primarily because I switch machines a lot and there's a higher probablility python has already been installed on the machine.

Posted: **Wed Dec 12, 2007 4:35 am**

Dwindlehop wrote:I like while(<>){}, therefore I approach every problem as something to be solved via while(<>){}. I have a hammer therefore everything appears nail-like.

Edit: Most times I write scripts, I'm automating something tedious. It's either essentially a shell script and I use perl for comfort reasons, generating input/munging output in which case I choose you, filter!, or trying to do something smart.

I'm very happy with my perl filters, but I'm willing to concede that perhaps it's not the right tool for routine automation or doing smart things.

Do you revision control your hammers?

Posted: **Wed Dec 12, 2007 4:56 am**

Jason wrote:I've used python primarily for string and file processing. I've been using python more than perl primarily because I switch machines a lot and there's a higher probablility python has already been installed on the machine.

I found it oddly amusing that I have the exact opposite installations problem.

As for usage, I write perl primarily for automation, but recently I've used it for everything from code generation (specialized C bindings from RPC x-files) to algorithm prototyping.

Posted: **Wed Dec 12, 2007 7:17 am**

Generally no. Code I share is in either CVS or BitKeeper, but stuff just for me doesn't find its way into a revision control system.

Posted: **Wed Dec 12, 2007 5:31 pm**

VLSmooth wrote:...it's just that the whole bless crap is ugly and a pain in the ass. Regarding perl's maintainability...

I said the same thing to you three years ago, and you told me I was crazy (not exact word).

So take that, fucker.

Posted: **Wed Dec 12, 2007 5:33 pm**

Dwindlehop wrote:Fakeedit: most of the time when I design something smart, I decompose the problem into a series of perl filters anyway. Libraries are for suckers.

just use bash so you can be like "bash! hammer! nail!"

Posted: **Wed Dec 12, 2007 7:44 pm**

VLSmooth wrote:
Jason wrote:I've used python primarily for string and file processing. I've been using python more than perl primarily because I switch machines a lot and there's a higher probablility python has already been installed on the machine.
I found it oddly amusing that I have the exact opposite installations problem.

On a few of my previous projects, we used to use a product that installed python by default. I don't really work with other developers, so no one installs perl. For a while, I used to have just the perl.exe in a shared folder, so that I could pull it down to a local directory and then just create a quick script there. That got annoying after a while.

Posted: **Thu Dec 13, 2007 7:54 pm**

Fairly interesting and somewhat related

My brother Peter Plamondon and I started Project 7 at Microsoft, which was the code-name for an effort to (a) get the .NET & Visual Studio.NET products opened up to non-Microsoft languages and (b) get non-Microsoft languages implemented on .NET.

You might think that this was "obviously" the right thing to do -- we certainly did! -- but at the time (1998-99), we had to fight all the way up to the #3 guy at Microsoft, Paul Maritz, to get approval and funding for the project (thanks, Paul!).

There was a LOT of resistance. Microsoft had just been burned by a non-Microsoft language -- Java -- and there were those who felt that Microsoft should be actively suppressing the emergence of new languages, not facilitating it. Fortunately, Paul recignized that the emergence of Java proved that Microsoft could not suppress the emergence of new languages...and that it shouldn't WANT to do so. Better to encourage their emergence, and to make it super-easy for them to emerge first, best, and only on Windows. This is what's happening now with languages such as F#.

In Project 7, Peter handled the commercial languages; I handled the academic languages.

One of the main reasons I wanted to open up .NET and VS.NET this way was to facilitate the miscegenation of programming languages -- the mixing together of ideas and features that can only happen on top of a platform (the CLR) that provides a simple, open, flexible DNA for programming languages). "Miscegenation" is a term previously applied by racists to the "horror" of inter-racial mixing. I use it advisedly in the context of programming languages, which are often approached with equally-strong biases favoring language purity, which I believe to be equally wrong.

The next step after mixing & matching features, I think, is a wholesale re-engineering of programming languages. If one can mix and match ideas and features freely within languages, then why not modularize these features? The history of programming languages has been the history of a succession of single, dominant, monolithic programming languages that each were the de facto standards of their day. A new language would bursting onto the scene with initial promise of advancing the state of the art, then become a drag on progress as the state of the art advanced beyond the current domiant language's central paradigm. A great example is C++, which became so dominant that the great ideas in other langauges -- such as Eiffel's use of contracts -- languished. A more modular approach to programming languages would facilitate the miscegenation of language features, allowing things like contracts to find their way into the mainstream much more efficiently.

Then, programmers would chose the best language to write each piece of a coding task, just as a carpenter uses a hammer for one task and a saw for another.

This modular approach to language functionality would (a) allow the more-rapid evolution of programming language functionality, and (b) be available first, best, and perhaps only on Windows, because no other platform has the necessary infrastructure (and presumably Microsoft has patented the holy shit out of the CLR and VS.NET).

If, at the same time, Microsoft were to aggressively support the use of VS.NET as a cross-platform development tool, implementing redistributable .NET equivalents ("the .NET Platform") on other operating systems, then this would de-commoditize programming, establishing Windows as the most efficient platform for developing applications for the .NET Platform (and thereby all other OS'), thereby ensuring that the best applications were developed first, best, and perhaps only for Windows. This could make it possible for Microsoft to regain the Cool Factor Cup than Linux et al. have recently captured.

Of course, this de-commoditization only happens if VS.NET, the CLR, and the novel re-engineering of programming languages allows such a big jump in programmer efficiency that programers who don't use it are outcompeted in the marketplace. That's what de-commoditization MEANS.

My two cents of free advice.

James Plamondon

Microsoft, 1992-2000

now CEO, Thumtronics Inc

The New Shape of Music(tm)

http://www.thummer.com

Austin, TX

Mohtalim

xkcd betrayal