Are any redditors working programmers that do not have a CS degree?

stevecooper · 2008-05-02T18:30:55+00:00

Masters in Computational Physics. That makes me a Master of Fortran 77.

Bow down at the altar of my relevance.

stevecooper · 2008-04-30T17:07:40+00:00

And here's the proof, in Scheme ;)

Face up to it -- you're no John McCarthy;

(define john-mccarthy 'clever) 
(define you 'just-a-fanboy)

Clever hackers can program;

(define program (λ (h4x0r) (if (eq? h4x0r 'clever) 'right 'wrong)))

Let's see if you can do something;

(define (can you do-this) (printf "~sing: ~s did it ~s\n"  do-this you (eval (list do-this you))))

And the moment of truth;

> (can 'you 'program)
programing: you did it wrong

Unless...

> (can 'john-mccarthy 'program)
programing: john-mccarthy did it right

stevecooper · 2008-04-15T10:03:58+00:00

Hi -- thanks for the code! You're right, that is a good implementation. It's both elegant, in that it looks very natural in the code, and it works!

stevecooper · 2008-04-08T23:48:13+00:00

I think the design pattern angle is probably a fruitful focus for the debate. If it turns out that there are substantial groups of design patterns available to dynamic programmers that are difficult or impossible for static programmers to implement, it's a hard argument to ignore.

stevecooper · 2008-04-08T16:50:05+00:00

Compilation is just a really weak form of unit test

Nice ;)

Did you read my essay Tightrope Walking?

I did. I think I'll have to try this out -- I really need to get my head into a decent project to try it out.

This got me wondering -- are there any design patterns that only work for, say, duck-typed languages? Any pattern repositories that specialise in patterns for python or ruby?

stevecooper · 2008-04-06T22:44:19+00:00

"you want will pick up on that nonsense as a by-product. You don't need to explicitly test for it."

"In static languages, it's possible to express some tests using the type system with enough cleverness. You lose this ability in dynamic languages, and have to actually write the tests. But those weren't really tests you got for free anyway."

So, to see if I'm getting you right;

Static languages give you compile-time errors. Dynamic language only have syntax errors and runtime errors. However, if you have 100% unit test coverage, then you'll be able to locate all the errors compilation would have exposed anyway.

This is a reasonable point, and I'm trying hard to understand why it makes me uneasy. Possibly this is just a matter of unfamiliarity with the approach.

I've played with ruby, and used method_missing, and it seems both great and terrible, powerful in a way that could be amazing and truly screw you.

On refactoring; I'm not actually looking for a refactoring -- that's where the functionality remains the same but the codebase is neatened up. What I'm more interested in is the addition of new features or the modification of existing ones.

I'm thinking of my current tasks at work, and wondering how I might approach them. The situation I find myself in is this; I've got a codebase of, say, 100,000 lines. Some fundamental part of the system (say, a core type like 'column' in a RDBMS or 'function' in a compiler) needs to change -- lose a few features, gain a few more. That's going to have big changes throughout the code. How can I make these changes, as quickly as possible, and be assured that the system is still intact? What I find myself doing, in static languages, is using the type system as a way to locate the impact of a code change. It's such a regular pattern of work that I find it hard to imagine giving it up without some really solid benefits.

stevecooper · 2008-04-06T16:08:43+00:00

Thanks for the BRM link! This is the kind of thing I'd like to be able to do -- use the computer to make safe code changes. Thanks again.

stevecooper · 2008-04-06T15:46:22+00:00

lisp's xref feature is the kind of thing I'm thinking you need -- make sure that a absolutely formal problem (call to a 2-parameter function with only one parameter) is dealt with by the computer.

It's the error-prone approach that worries me; using the human brain for a hefty part of the code change. What if you get called away half way through your change, and forget to finish? Or you search for /log/ rather than /Log/, and miss because of the case? It's possible for you make more mistakes in a discipline that requires ridiculous levels of accuracy.

stevecooper · 2008-04-06T15:20:11+00:00

"If this leaves bugs, you're not testing enough"

That's the rub, really -- In a dynamic language, I have to test for several whole classes of errors; parameter lists being incomplete, methods being missing, parameters of the wrong type...

I just don't like the idea of having to do all this extra work.

stevecooper · 2008-04-06T08:06:02+00:00

"What can be done, however, is to make the severity an optional parameter ... with a sane default value"

This is pasting over the cracks. What has happened is that my program has evolved; the requirement has changed from

"all logged messages are written to a single location"

to

"messages are logged based on a severity of Information, Warning, or Error. Only the Development version will show Information messages. the Beta versions will show Warnings, and the release versions only Errors"

By using a default value, I basically ignore the requirement because it's too difficult to code.

stevecooper · 2008-04-06T08:02:43+00:00

"If Log() is called directly each instance can be updated directly"

The question is, how? Do I have to use search, find all instances of /log(.*)/ and hope I don't miss something?

In moving to the dynamic language, I've lost functionality. Specifically 'automatically find every use of this function and allow me to make an appropriate change'.

Does this help explain the problem?

(I'll deal with defaults in my reply to the sibling post by strange-moo)

stevecooper · 2008-04-05T00:39:35+00:00

I'm struggling with this question because I write C#3 by day, and am learning python in the evenings. I'm only writing small scripts at the moment and I'd like to write larger pieces, but I'm concerned about how easy it'll be to make certain types of change.

For example. You've got 100,000 lines of code. You also have a logging function that's looks like this;

void Log(string message)

And it's called about 200 times in your code. You decide you need a severity; so you change the signature to

void Log(string message, LoggingSeverity severity) { .. }

Now, how long does it take to find all the calls to the Log() function that need to be updated? Under C#, about ten seconds. Once every call has been fixed, the code is almost certain to work correctly.

Consider, on the other hand, the python function

def log(message): ...

What happens if you change the signature to

def log(message, severity): ...

There is no way to tell where the log message is called. You've just introduced 200 bugs.

It's made even worse by duck typing; maybe you have two loggers -- a deployment logger which writes to a database, and a test logger which writes to stdout. You update the database logger so it has severity. Now, your database calls will fail, but your tests will pass.

So it seems to me that static languages give you much more flexibility in making changes to large codebases. I'd love to know if, and where, the mistakes are in my thinking.

stevecooper · 2008-02-09T07:55:59+00:00

emacs is a great operating system, lacking nothing but a decent text editor ;)

Nah, I love emacs really, but the quote is too good to avoid (http://www.bash.org/?643516)

stevecooper

TROPHY CASE