But I’m wondering, can any use of programming language really be called abuse? The language designers and creators put the ability to create the hack described above into the language. If they didn’t want you to do things like that, why put the ability in there at all? Using undocumented calls within the language to do strange things is one thing, but simply using calls within the language itself?

What are some of the best “abuses” you’ve seen of a language?

And so for 20 years now these folks —
*the* shining lights, in many ways, of “practical” programming
language, operating systems, and general systems research — have
continued to fail to “get” the fundamental practical needs of everyday
programmers working in The Real World. “Go” is just another language
written first for the compiler and only secondarily for the programmer
— and stuck in a 70s mindset* about the relationship of that
programmer to the (digital) world within which they live and work!
(But hey, it compiles fast! Which is, of course, THE problem that
really needs addressing.)

He then goes on to talk about some aspects of languages that frustrate him.

J.H.C, folks, it’s nearly 2010. Let’s get a few things straight:

– most programming involves schlepping a few but complex data types
between different string representations
– programmers have become plumbers and documentation-archaeologists
mostly, which is sad and uninteresting
– programming languages are for *programmers* — not compilers and
compiler-writers
– until you make the everyday, “simple” things simple, it will
continue to be a dark art practiced by fewer and fewer
– any language that makes you explicitly import an IO module to
read a file or stdin is fucked
– declarations are a pointless anachronism (same for explicit
memory management)
– if I have to understand category theory to write a program that
does IO, IT IS A NON STARTER!
– less stupid line-noise syntax and punctuation, people

I don’t understand why the need to compile fast is such a big deal. If your programming language makes you write so much code that it takes more than a few seconds to compile, you should probably look at using a different language. Here are some things that I’d like to see in a programming language that is designed for programmers rather than compilers or computers.

1) No typing – That’s not to say that I can’t declare my own types, classes, objects, etc… But that calls to objects should be type independent. (e.g. messaging and dynamic dispatch)

2) Built in unit testing – I should be able to declare contracts on the methods and pass/fail criteria. The tests should be run as part of the compile step or interpretation (if the language is compiled or interpreted)

3) Jellybeans

4) Automatic inclusion of libraries based on path and usage. – I don’t mind having to pull in a library to do file I/O or consume some other kind of data like ATOM or JSON. But at compile time, if I have referenced any of the objects contained in the library, all of the references to the library should be handled for me automatically. Any name collisions should be compiler warnings so I can specify which library to use by in my code or make the reference explicit in some other way. I like Pythons path based module convention, the language should just search the child directories for a library if the library isn’t already included in the base language pack.

5) Anytime a design pattern emerges, it should be re-factored into the language itself.

6) It should be a pocket language, have a set of keywords and syntax that is small and compact but still understandable. JavaScript and C are good examples of pocket languages. It’s easy to pick up the syntax.

I’m sure there’s more that I would add. What kinds of features would you like to see in a language oriented towards programmers rather than compilers?

Script# (Script Sharp) – writing javascript in C#

Both Jimmy and roy have great posts discussing JavaScript. Roy is looking at it as a C# developer lured by the many, many articles about how jQuery is the only thing that makes JavaScript worth using and using Script# to abstract away some of the messiness and pain usually associated with writing JavaScript. Jimmy discusses the merits of JavaScript itself and how it has changed how he approaches writing C# code.

One thing I like to point to is a great quote I heard on Twitter

Java is to JavaScript as ham is to hamster

JavaScript actually has more in common with Scheme or Lisp than it does Java or C#. I first realized this when I saw that Douglas Crockford had re-written all of the examples in The Little Schemer
in JavaScript. It’s easy to miss that fact when you see all of the pseudo OOP noise like “var foo = new Foo();”. But when you see how trvial it is to implement something like a map method in JavaScript, you realize how powerful the language can be. Most of the hatred for JavaScript comes from two things I’ve found:

1. Broken DOM implementations – every browsers implementation of the DOM is broken in one respect or another.
2. A misunderstanding of either scope or inheritance.

Roy has a great point about the lack of good tooling surrounding JavaScript. There are excellent libraries like jQuery and PrototypeJS, but the usual tool support, intellisense, re-factoring, profiling, is a little more difficult to come by. I’ll address this in another post as I feel a lot of people are new to JavaScript and are struggling along with some substandard tools.

The book starts out with an introduction to Python itself and continues with a general description of how IronPython can use .NET types. It starts off by showing how to build a Winforms app using IronPython. If anything exposes the cruel, unnecessary complexity of .NET, it’s got to be a Winforms app. The IronPython examples are easy to follow and it’s always fun to create and manipulate a Winforms app using the IronPython console.

Chapter 4 talks about using Design patterns in IronPython. This is a refreshing change from most language books where patterns aren’t mentioned at all. The chapter builds an IronPython application and uses the MVC pattern for the overall architecture and the command pattern for the implementation of the menu bar events.

Chapter 7 discusses agile testing and unit testing using IronPython. I almost dropped the book in amazement. Unit testing is almost never mentioned in any language book and is relegated to a niche or advanced topic. Find a book about any other .NET language that mentions unit testing that doesn’t have the word “testing” in the title. This alone sets the quality of this book far above other language books I have read. It’s not just enough, in my opinion, to discuss the syntax of the language. You have to teach the reader how to use the language in your everyday work.

The next section, section3, deals with a few core UI frameworks commonly used during .NET development, WPF, Silverlight, and ASP.NET, as well as showing how you can use IronPython to administer your system. Performing tedious tasks is my most common use of IronPython. I use it to automate moving files that fit a specific pattern out of my “downloads” directory to their proper places. It was great to learn a few new techniques for using IronPython in Powershell.

The last section talks about extending IronPython using C#, something which it sounds like should be avoided unless you just can’t achieve decent performance with the equivalent IronPython code, and using IronPython as an embedde scripting engine. Python is used a lot in game programming because it’s easy to embed. The nuts and bolts of the game engine will be written in low-level C/Assembly while the game logic and story is written in Python. I love the idea of having an embedded scripting engine in my application that will allow me to quickly extend my application at runtime. The user need to perform a new calculation on some data? Just send them an IronPython script and have them put it in a directory. It’s a great idea and the book describes exactly how to do just that, even if it does use a little too much jargon at times. These are advanced topics and you probably shouldn’t undertake them unless you have a good understanding of the basics in any case.

My overall feeling about this book is that it’s a great book. The authors use the same humor and dry wit that Python is known for to great effect. Making the digestion of a very different language easier. I’m sure that as I continue to experiment with IronPython that I’ll keep this book close at hand.

The re-factored code using the Repeat.Times methods.

You can see how the second code sample is much cleaner than the first. A lot of the messiness of the first code sample comes from talking to the compiler instead of talking to objects. What do I mean by that? Well, in the first example we have to tell the compiler what the delegate should return

You'll also notice some ugliness inside of the delegate body.

Here, I was incrementing a class member and checking to see if it was odd or even. If it was even, I'd return true, otherwise I'd return false. This allowed me to control the number of times the IDataReader.Read() method would return true. In this case, it would return true once, then the variable would be incremented to an odd number and the Read method would return false.

That's all part of me telling the compiler what to expect, when what I really want to do is just tell my objects what to do. This episode of the Alt.net podcast also talks a little bit about class-based programming versus object-oriented programming.

The code base, while touted as a "a real-world sample written using ASP.NET MVC.", is not without some problems. The commentary on Twitter soon after it's release was pretty negative.

This is why Oxite is not good. http://pastie.org/339644

Rob Conery has a great post where he outlines some of the issues with the Oxite code base and how they can be fixed. He has already offered some patches to the team.

That's what I mean when I say this is a great thing. Since the team is doing all their work out in the open, we get to see how it evolves. I fear that a lot of the ASP.NET MVC code that we see written the first few years after it is released will look very similar to the Oxite code. Hopefully, the refactoring of the code base into something that embraces the strengths of MVC will be done in public as well so that first time MVC developers who find themselves writing the same code that the Oxite team has will have a lot of resources available.

I'd encourage everyone interested in the ASP.NET MVC product to watch the evolution of Oxite closely and contribute to the development.(1)

(1) That doesn't include me for quite some time as we're getting ready to have a baby soon. You don't want to see code I've written on only 4 hours sleep over two days.

Mike Moore was kind enough to invite me on the alt.net podcast to talk about the recent jQuery announcement by Microsoft. Chris Brandsma, Rick Strahl, Dave Ward, Bertrand Le Roy, and Steven Harman were also on the podcast.

This was a great discussion. It was especially nice to have Bertrand during the discussion. If we had any questions about how or why Microsoft did something, we could ask him. I was happy to hear that one of the reasons they chose jQuery was because they didn't want to write their own CSS selector functions for MS AJAX. It's nice to see that Microsoft sees the benefit in not always reinventing the wheel. Now, any new features or improvements that Microsoft would have made to their own selector engine can be contributed towards jQuery, making it a better product for all of us.

Some topics we cover in the podcast:

• What is functional programming, and why should we care?
• Types of applications that would and wouldn’t benefit from F#
• How F# differs from C# 3.x and Javascript
• How F# is being used (games, scripting, data analysis and scrubbing, etc.)
• F# pattern matching
• Using F# in your C# or VB based applications today
• Getting started: F# Interactive, reading the F# source, books and resources
• Interaction with DLR
• Functional features we’d like to see in C# and VB
• Spec# and Sing#

The post containing the podcast is turning into a great resource if you are interested in Functional Programming and F#. Matt provided us with a lot of links and we've been adding new links as we find them. If you know of any Functional Programming or F# links, feel free to leave them in the comments here or at the Herding Code post.

I found a great answer over in this forum.

In both Java and .NET, classes can only inherit from one class but a class can implement multiple interfaces. So consider the following code.

Essentially the answer is: The compiler tries to run the code specified by the static method in a class. Since an interface doesn't provide an implementation details, there is nothing to run. You could, if the compiler would let you, cast the interface to the concrete type that's actually being represented. But that defeats the purpose of declaring an using an interface.

I do wonder if type inference could be used to route around this problem?

New Languages Considered Harmful

I can't disagree more with this post.(1) There's no research or study that shows that learning impedes further learning. Once you learn how to program, moving between languages becomes easier. Every language has some kind of flow control syntax, some way to declare a variable, and some way to encapsulate code. You do have to think a little differently if you switch between OOP, functional, and procedural languages. But even Scheme has an if-else statement. It doesn't take much effort to learn a new language, but it does take a lot of effort to master a programming language.

1. I think I could disagree more with this post if I really tried, but I know I disagree enough to make a post.