Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)
+ -

  Comment: SSD != RAM (Score 1) on 2009.11.10 10:39

by ziggy on 2009.11.10 10:39 (#71082)
Attached to: MySQL on a ramdisk
SSD is a kind of flash, and doesn't perform at all like RAM. It's similar in that there's no rotational delay. Writes tend to be staggered so that each bit gets a comparable number of writes (which leads to much worse fragmentation, especially in write-heavy environments). You might get decent performance off of the SSD initially, but performance will likely degrade over time given a balanced or write-heavy workload.
Read More 8 comments
Comments: 8
+ -

  Comment: winheight/winwidth (Score 1) on 2009.10.27 9:48

by ziggy on 2009.10.27 9:48 (#70989)
Attached to: Switching and resizing windows in vim

There's also :set winheight and :set winwidth

Each of these set the default height/width of the current window, so whatever you switch to takes up the appropriate amount of room.

Read More 3 comments
Comments: 3
+ -

  Comment: Re:Perception is Reality (Score 1) on 2009.07.25 13:14

by ziggy on 2009.07.25 13:14 (#69632)
Attached to: What Does the Outside of Perl Look Like?

Steve Yegge covered these points at OSCon a few years back.

The root problem is that geeks don't do marketing well, don't respect marketing, even when marketing is the most important thing we can do for ourselves and our projects. (It's been a while since I listened to his talk, so my memory is fuzzy here.)

One of the interesting points he made is that GTE (the phone company) had a very bad reputation among its customers and in its service area. They conducted a poll to see what it would take to improve their reputation and brand perception, how long it would take, and how much it would cost. As Steve tells it, if GTE had absolutely stellar performance from this day forward until the end of time, and an unlimited marketing budget to improve perception of the brand, it would take 25 years (or about a generation) to lose its bad brand perception.

So they chose to take a different path: change the name of the company to Verizon, something that had no embedded brand perception to work against.

"Perl" now has 20+ years of compounded bad perception in the parts of the tech community that cares about it. "Perl 6" has had about half as much time being badly received by the same group. If there were an infinite budget for marketing campaigns and PR surveys, those opinions won't change easily.

Read More 27 comments
Comments: 27
+ -

  Comment: False Dichotomy (Score 1) on 2009.04.04 18:05

by ziggy on 2009.04.04 18:05 (#68017)
Attached to: On Language Height and Optimization

Dichotomies can be categorized into exactly two types: true dichotomies and false dichotomies. :-)

This, my friend, is a false dichotomy.

Modern haskell believes strongly in the second option. It's all about making and reusing the best abstractions, and hoping the compiler can figure it out. Most don't, ghc often does, but not always.

The new fad in the haskell community is stream fusion, or writing your code in a pipelined manner that allows a stack of maps and filters to be condensed into a single traversal over an aggregate data type. Switching out linked lists of characters in favor of C-like "bytestrings" is another popular theme.

What allows a compiler like ghc get C-like performance out of code like this is a liberal sprinkling of compiler hints and writing high level modules that do care about byte level operations.

All compilers (save one[*]) are dumb programs that need a lot of help to figure out how to make performant code. The question is where, when, how and if its exposes the ability to do bit-level and byte-level tweaks.

*: Any compiler that supports COME FROM cannot be deemed a "dumb" program. :-)

Read More 4 comments
Comments: 4
+ -

  Comment: Code as contracts (Score 1) on 2009.02.25 16:26

by ziggy on 2009.02.25 16:26 (#67617)
Attached to: Writing Legal Contracts as Code

You would probably be interested in the converse: code as contracts -

Production systems based on this work (or at least this line of thought) are in use on Wall Street, except using OCaml instead of Haskell.

Read More 4 comments
Comments: 4
+ -

  Comment: Wrong Audience (Score 1) on 2009.02.17 10:55

by ziggy on 2009.02.17 10:55 (#67447)
Attached to: How To Not Teach Programming (Haskell)

What on earth could convince someone writing a programming book for beginning programmers that having them type in examples they can't type in would be a good idea?

I think I see your problem. Programming in Haskell is an academic text. It's written by a professor who is interested in approaching Haskell for students of mathematics. The target audience will understand the use of standard math symbols and their translations into ascii. That's one reason why it's so expensive yet so thin. It's not meant for "beginning programmers".

For a more approachable introduction to Haskell, you should be looking at Real World Haskell. That book is geared towards a more typical O'Reilly audience -- practitioners and programmers. It's not an introduction to programming (Haskell as a first language is not really a good idea), and expects the reader to have a background in some other language before beginning.

Read More 9 comments
Comments: 9
+ -

  Comment: Re:Not a strong typing kind of bug (Score 1) on 2009.01.05 16:00

by ziggy on 2009.01.05 16:00 (#66739)
Attached to: Code Coverage and the Zune Bug

All of this, of course, if from a typing newbie, so if I'm talking complete bollocks, feel free to correct me!

You're talking complete bollocks. :-)

The kinds of things a strong static typing system can do is let you create types like DayOfYear, which let you specify a single calendar date, and prevents such nonsense like the 47th of April as being a "date". From there, you can create functions like addDays that take a DayOfYear and an integer number of days and return a new DayOfYear.

What this code was doing was taking a count of days since the beginning of time, and figuring out the current date by subtracting one year's worth of days at a time, and producing the current year and the current count of days since the start of the year. If we were dealing with a calendar that didn't have leap days, it would be a simple matter of calculating day_count div days_in_year and day_count mod days_in_year. But date math is more complex than that, so...

What type checking cannot do is infer specific magic properties about a simple counter used in a specific context. Adding and subtracting numbers is always just adding and subtracting numbers. If you want a type checker to help you out (in Java or in Haskell), then you need to define a new type with new behaviors that more closely matches the domain, whether you're talking about date math, tax math or statistical probabilities.

Read More 7 comments
Comments: 7
+ -

  Comment: Not a strong typing kind of bug (Score 1) on 2009.01.05 13:25

by ziggy on 2009.01.05 13:25 (#66736)
Attached to: Code Coverage and the Zune Bug

First, I appreciate the schadenfreude here as much as the next hacker, but it appears this bug was in the Freescale code for the platform, not the code Microsoft wrote for the Zune. So it effects more than just Zunes...

Second, the "some type inference systems" is misleading. The one type inference system that Andrew Koenig and MJD discuss is the Hindley-Milner type system, which is used in ML and its descendants (OCaml, F#, Haskell, etc.). Koenig's example demonstrated that a recursive algorithm would have never worked properly because it was missing a base case. That's totally different from a while loop in an imperative program. No type inferencing system can find a bug like this in an imperative program.

Third, this is not the kind of problem simple code coverage would be able to isolate. What happens if $days is 367 and $year is a leap year? Then the inner if branch fires, $year increments, and $days decrements by 1 leap year.

That's why this code works perfectly, except for one day every 4 years -- the last day of every leap year. You could try 1000 random inputs and demonstrate all branches are exercised, and still miss the case where $days = 366 in a leap year.

Date math is hard, and full of corner cases like this. This is a problem that by its very nature isn't amenable to automated reasoning, whether you're talking about type inferencing, theorem proving, automated testing or code coverage analysis. Your best bet for all date math related code is to build up a body of known edge cases and try them all, in a brute force manner.

Read More 7 comments
Comments: 7
+ -

  Comment: Re:Culture shock (Score 1) on 2008.12.12 15:24

by ziggy on 2008.12.12 15:24 (#66446)
Attached to: for file in @frack!

What does it return in ovid context?

It always returns ovid in an ovid context. In a strongly typed language, the compiler will never allow you to call it from a non-ovid context. I suppose you could overload foo() to return a virgil, horace, or even homer in other contexts, but I've never needed to do that.

Read More 13 comments
Comments: 13
+ -

  Comment: Re:Culture shock (Score 1) on 2008.12.12 12:40

by ziggy on 2008.12.12 12:40 (#66441)
Attached to: for file in @frack!
I think you misread that. Anyone can ask foo() for an ovid. :-)
Read More 13 comments
Comments: 13
+ -

  Comment: Culture shock (Score 1) on 2008.12.12 10:56

by ziggy on 2008.12.12 10:56 (#66438)
Attached to: for file in @frack!
I can't think of any non-perlisms leaking into my Perl, but I find myself typing this all the time in C# :

  public ovid foo() {
    // ...
  }

:-)

Read More 13 comments
Comments: 13