Oliver Steele

There are both kinds of developers. I always thought Oliver Steele did a good job of explaining this here:

http://osteele.com/archives/2004/11/ides

Here's my take:

The ability to write in a language that doesn't require excessive amounts of boilerplate code means I'm much more likely to refactor as the code evolves. Seeing an algorithm on one page, localizing and separating the logic cleanly with higher level constructs, easily translating the intuitions in my head to a coded solution, being able to dive into any part of the code without getting lost in the redundancy and residue of IDE vomit, etc... is all really valuable. Getters and setters that take up more than one very short annotation are eyesores, and the mere act of coughing them up into the code was never a bottleneck to programming speed no matter how bloated they get.

The act of automatically renaming classes or variables, along with all the other code-shoveling refactoring support that IDEs provide is a miniscule subset of what refactoring is really about. The real refactoring work is done in your head. You need to look at the code and comprehend it in ways that aren't obvious, so that you can reorganize it to be simpler or maybe extendable. This kind of work cannot be done by an IDE; however, it can be aided by using a nice expressive language that gets to the point and doesn't distract you from the problem.

When it comes down to building, deploying, and automation of other menial tasks, I'm not stuck with…

Thanks for all the good points. To be honest, I'm not sure what you're trying to say. I've been coding in python for years and Moka was built from my annoyance using functional paradigms with the stdlib.

As you clearly showed, Python doesn't have an uniform syntax to deal with this paradigm. I.e. there are lots of different constructs and, as you said, common idioms or patterns. Have you already argued with a Java programmer saying that these 'Design Pattern' are just a limitation of the language.. whereas in Python you'd probably just use a simple Dict (or whatever)? I'm sure you did. I feel the same with the idioms and patterns.

See, in Clojure (And Arc, and even Ruby), there is an uniform syntax.. whereas in Python we've got itertools, list comprehension, builtins map/filter, random builtins functino such as sorted().

I have to agree with you that Moka is not Pythonic in the There's only one way to solve a problem as we add a new way. However, Moka was created because there was so much inconsistent alternatives..

However, Moka is Pythonic in how it behaves. God knows I could have use all nifty hacks to make it behaves magically.. but I chose to take the explicit route by overriding list/dict. I could have used string interpolation for function (See http://osteele.com/sources/javascript/functional/); but instead went the Pythonic way with standard lambda functions. Maybe you are right about the operator keywords shortcut (i.e. using List().keep(operator.eg) instead of…

> auto-complete and instant doc lookup help you figure out what's available to call and what the various methods and classes do. That's also useful if you only use a particular library occasionally and just don't remember how it works.

Lucky for me, I can have those things with languages like Perl and Ruby without having to resort to an IDE.

> on a 500k+ codebase there are probably enough methods named "add" that just doing a text search is going to be pretty painful.

The kind of tools you describe as being better than a text search are, in essence, just text search (and replace) tools. They're obviously much more powerful than the search and replace tools familiar to many MS Windows users thanks to the style of search functionality offered with editors like Notepad, Wordpad, and even MS Word -- but then again, so are the search tools available in a typical Unix environment, especially when using an editor like Vim or Emacs.

> I think that there are other situations, primarily for working on larger projects but also for people new to the language or who use it less frequently, where the benefits of a really good IDE would still help out Ruby.

I think that applies more for people who are used to an IDE approach to programming, really. The kind of development done with Ruby without an IDE near at hand actually uses a very different approach to development than an IDE-centric approach, and for someone used to that IDE-centric approach, having an IDE to help make the…

I use the Google style guide as well since it's required by my job and while I have learned somethings from it I'm not a fan.

80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief. I find that naming things descriptively and an 80 character limit are at odds.

I'd rather read

maxCombinedUniformVectors = maxFragmentUniformVectors + maxVectorUniformVectors;

than

maxCombinedUniformVectors =
maxFragmentUniformVectors + maxVectorUniformVectors;

or

maxCombinedUniformVectors = maxFragmentUniformVectors +
maxVectorUniformVectors;

I admit it's kind of useful for side by side diff tools but in my previous 27 years of programming I never felt like "If only this code was 80 characters I could read the diff".

More importantly though, the Google Style guide is written by Java programmers to try to make JavaScript into Java, totally ignoring all the benefits of treating JavaScript like JavaScript. That has it's benefits, especially for Java programmers. They don't have to learn some of the cooler things about JavaScript. They can go on treating it like a traditional oop language. And they get static type checking.

On the other hand, all of these FP concepts are…

I would say that there are two important things to consider:

1. Understanding how a compiler works without getting bogged down by programming language details - This means that you should try and look at compilers written in Standard ML or Ocaml (my favorite), since that would be much easier to follow. For example -- a datatype can be much more succinctly expressed as
type any_value = Int | String | Float

rather than across 4 classes (as in the Java case).

2. Start small, and understand it in chunks. For these, a lot of web based resources are ideal. For example, to understand regular expressions, it would be nice if you were able to visualize them, and play around with them visually -

http://osteele.com/archives/2006/02/reanimator

I would also look at simple examples of interpreters, and build up from that, looking at examples of toy compilers:

http://min-caml.sourceforge.net/index-e.html

These will help, of course alongside a book like Appel's or the Dragon Book.

This PHP code https://github.com/osteele/wideurl.com/blob/master/wideurl.php turns e.g. http://osteele.com/archives/2006/04/wideurl into `http:​//w-i-d-e-u-r-l.com/aitch-tee-tee-pea-colon-double-slash-oh-ess-tee-double-ee-ell-ee-dot-see-oh-em-slash-aye-are-see-aitch-eye-vee-ee-ess-slash-two-double-zero-six-slash-zero-four-slash-doubleyou-eye-dee-ee-you-are-ell`.

It was loosely inspired by a BBC broadcast I heard during the very early days of the web. The announcer said something like “If you would like to learn more about this radio program, enter the following into your browser: aitch aitch tee pea colon forwards-slash forwards-slash bee bee see period see oh em forwards-slash — oh, never mind.”

My hosting provider eventually took it down, because URL redirectors can be used for phishing.