Category Archives: Languages

Can a language be abused?

K. Scott Allen has a great post showing an “abuse” of the lambda syntax in C#.

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?

We need a language for programmers

Here is a great rant about “modern” programming languages.

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?

JavaScript: Not for the faint at heart?

JavaScript: A tool too sharp?

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

hamster2.jpg

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.

Review: IronPython in Action

I’ve always wanted to use Python more but it’s difficult because the .NET Framework is such a walled garden in terms of interoperability with other programming languages. Mostly I use it to write little one off scripts when I want to move a bunch of files around or parse some text. I was really excited when Manning asked to to review IronPython in Action because I wanted to dive a little deeper into Python and possibly use it in some web applications. “IronPython in Action” makes it easy to get started using IronPython right away.

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.

Object oriented programming vs. class oriented programming

In the last post, the code was pretty clean. Our resident Rhino.Mocks guru at work, Sean, left a comment saying that the new code was much better than the Do-Func stuff I had before. Sean was the one that pointed me to the Repeat.Times methods in Rhino.Mocks. I thought I’d post the old code that I had cobbled together from a StackOverflow answer.

           IDataReader reader = MockRepository.GenerateStub<IDataReader>();

            reader.Stub(x => x.Read()).Do((Func<bool>) delegate()

                                                           {

                                                               m_NumberOfTimesIDataReaderHasBeenCalled++;

                                                               return

                                                                   (m_NumberOfTimesIDataReaderHasBeenCalled%2 != 0);

                                                           });

            reader.Stub(x => x["ID"]).Return(Guid.Empty);

            reader.Stub(x => x["FullName"]).Return("Test User");

 

            List<UserDTO> list = SearchProvider.ParseUserData(reader);

            Assert.IsNotNull(list);

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

            IDataReader reader = MockRepository.GenerateStub<IDataReader>();

            reader.Stub(x => x.Read()).Return(true).Repeat.Times(1);

            reader.Stub(x => x.Read()).Return(false);

            reader.Stub(x => x["ID"]).Return(Guid.Empty);

            reader.Stub(x => x["FullName"]).Return("Test User");

 

            List<UserDTO> list = SearchProvider.ParseUserData(reader);

            Assert.IsNotNull(list);

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

Func<bool>

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

m_NumberOfTimesIDataReaderHasBeenCalled++;
return (m_NumberOfTimesIDataReaderHasBeenCalled%2 != 0);

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.

New ASP.NET MVC sample – Oxite – Needs some TLC

Last week the MIX online team announced that they are releasing the ASP.NET MVC code that powers their MIX Online blog as open source at CodePlex. This is a great thing.

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

browsing the Oxite source… wondering how many people will try to learn from this mess

@robconery because microsoft doesn’t deal with foibles with courage, i expect oxite will be allowed to degrade yet more customer potential

Oxite source is being slaughtered by the alt.net crowd; sad thing is, since its by MS others will use it as guidance on how to do MVC

@cwoodruff please, please, please do not use Oxite as a guide when doing MVC… PLEASE DO NOT

@lazycoder if u read the code, it’s actually a collection of anti-patterns of MVC… I hope people are not going to learn from it

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. ;)