Dependency Injection Presentation

from Jim Weirich, the maker of Rake

Dependency Injection: Vitally Important or Totally Irrelevant?

The answer is, of course, in the middle :D

Closures in Ruby and Smalltalk

Matz's talk on Blocksin Ruby

and Memoranda's comparison Smalltalkvs Ruby

You may want to work with some aspect of selected employees;
for example, to collect the spouse names of all managers.
In other words, select the managers from the employees and collect their spouse name

Smalltalk

(employees select: [:each | each isManager])
collect: [:each | each spouseName]

C#
foreach(Employee employee in employees) {
if (employee.IsManager) {
result.Add(employee.SpouseName)
}
}


Which is closer to "english", which represents better our intention (mentally)?
I find the C# solution a little bit low level: we have to many implementation details.
Smalltalk is more abstract, it says exactly what it does.

ps.
Anothe nice approach is the Smalltalk project: where:
employees
project: [:each | each spouseName]
where: [:each | each isManager]

Credits to RichardA. Demers

Bistro

A bistro is a place in France where people meet to share coffee and small talk.

no new releases since 2002. Is the project mature, or dead?

lesscoder

I've found lesscode.org.

Some nice blogs about dynamic languages (python, ruby, perl).

for instance this: j2ee vs rails
Whhooau!

I think I am a "lesscoder". (talk like a pirate is very funny :D)

Smalltalk Selects

Without language syntax extension:
here and here

and some Smalltalk Quotes :D

Agile Testing with Dynamic Languages

from this entry:

Jython : Anybody coding in a statically compiled programming language that is not using a dynamically typed programming language for the tests, has missed a golden opportunity for a productivity leap. In the C world, CPython. In the .NET world, IronPython. In the Java world, Jython.

Also check this example.

While the original comment refers to the Java world, what options do we have in .Net.
What Dynamic languages are available (except VB.Net which I personally don't like)?

- IronPython
- Smalltalk# (see some implementations details here: life is hard without the Smalltalk VM :D)
- Ruby.Net Bridge (Rook, Ruby.Net and others implementations for .Net are still "primitive")
- Boo. (has some nice features !!!)

Probably for tests I would go with IronPython/Boo.
Smalltalk# seems a very nice alternative for development. I have to see how it copes with the VM limitations. (#Dilbert would be a nice exercise).

The downside of the Ruby bridge is that you have to install 2 things: Ruby and the bridge.
And it is slow (cca 5x, I've read somewhere). That could affect the Continuous Integration.

Object Oriented Database Systems

A new portal is at odbms.org
Some whitepapers can be found at db4o

Dirty Glasses

Incidentally I've seen that James Robertson linked an
entry about Thoughts on Domain Languages.
Here is his article: Closer is Better.

I found the comments really interesting:
[Anthony Nassar]: I've just seen the specification for C# 3.0. Good heavens They've added what look like some of the features of dynamically typed languages, but making C# all things to all people is going to open the door again to the coding style I remember from VB.NET.

[james bridger], on C# and LinQ: For some reason this is getting lots of love at the moment - I've only seen one negative comment on it. Maybe I'm just missing something...

[Tom Sattler]: The most annoying thing about this original post is referring to Smalltalk in the past tense. Hey, world, it's STILL HERE, dammit.

First, I must apologies to Tom Sattler: I know you are "here", so is ruby, eiffel, haskell, lisp.
But you are not here in the minds of the people who decide which technology will use on their projects. And we know why: for java/c#/c++ you will always get developers, and there is a lot of people who use it. This doesn't make it better, but it makes it safer as an investment.

And this whole push up movement gets with the numbers
(developers, developers, developers) inertia:
the bigger is the mass of the developers, the "easier" will be for the people to read these programs, more components are made available on that platform, more speeches are on this thema, more jobs will be, more people will like to learn technology X to get a job, and so on.

So in the end it gets to that: how fast are you getting the critical mass, how fast can you sell your stuff to a "flock" of developers, until they follow you until the end.

I think there are few programmers who can appreciate the elegance of Smalltalk. (Personally I like ruby better: I've got intoxicated with the C/C++ syntax for more than 10 years, so it is very hard for me to quit: I just love the dots and the parantheses :D)

Now about C# and LINQ: Yes, "Good Heavens". I already posted on that, and I don't understand it either. They (Microsoft) already have a product which does all that LINQ, and it is called FoxPro. Where is that now? If it is so good, why isn't it ported to .Net? Why don't they push the VisualFoxPro, like they did with C#?

Why can't we take a step back, and realize that "Less is More".
With less language baggage, your programs will be easier to write and maintain. With less, but better programmers, you can advance faster than with a herd of medium developers.

[Troy Brummel] said: I can read Smalltalk, and write in it, but there's nothing in it that I can pick up and show to a domain expert, have her read it, and say "yeah, that's what I meant." And, I don't think it comes any closer to doing that than any other language I've used.

I see the problem from another angle: our job is to model a domain, and every "using", "lock",
"var", "select" is a baggage which we carry and makes our job more difficult. This stuff I have to read, understand, understand what the others meant by using it. All this "baggage" stays in your way, it "hides" the domain from you. That's why we train ourselves, to be able to carry (and don't feel) this burden. (I see that Troy is a very strong developer.)

Metaphor: My glasses are dirty, and I see the "domain" with spots. :D

ps. Another post about curving the learning curve.

Preview C# 3.0

Based on an analysis found here

1. Implicitly variable types

var i = 5;

Somebody said, in the context of usability: "Don't make me think".
This is not the case: the code is easier to write, but more difficult to read.

2. Object Initializers

Point p = new Point { X = 0, Y = 1 };

I hope this does not encourage people to use setters.
To put everything in the constructor, and eliminate the Setters,
would be a much more object oriented approach:
new Point(0,1).

...and probably faster: if we watch the IL,
two extra calls to the setters are made.

(Discussion about why getters are good, setters are bad.)

3. Anonymous Types

hmmm...
I cannot see how this would make the code more readable/maintainable.
Maybe for LINQ stuff ?

4.  Extension Methods
Ahhhh... This is a trick to extend "sealed" classes.
(Pls. read multiple-inheritance hack, partial implementation of ruby-mixins).
Eiffel supports both multiple-inheritance and .Net,
so why are we hacking around?

By the way, why do we have sealed classes?
Why am I, a client who want to use your classes,
obstructed to extend your work,
with my extra_funky_functionality?
Isn't your class Open-Close?

5. Lambda Expressions

Great!!! Finally the "modern" languages are approaching Smalltalk.

6. D/X Linq

I really don't understand this decision. Instead of "minimizing" the (syn)tax,
Microsoft is making C# more and more complicated.
Why can't we have a clear separation ofconcerns:
- here is the bussiness logic,
- here is the persistance layer, with this DB,
and this is how is mapped(SQL commands).
iBatis makes a really nice job with the databases.

So what we will have: a big FoxPro (sorry VB/C#) soup,
which nobody can maintain.
No problem, than we can (re)start from begining.

ps. Another analysis on Mixin-Closure/Block-DynamicProxy

Problems with using stored procedures

Dale Asberry here

Thoughts on Domain Languages

Smalltalk is close to the domain.
Ruby, as well.
Eiffel, too.
Haskell as well.

from this interview:

AT: Most languages require you to pay a "language tax": code that does nothing with the main algorithm, placed there only to make the computer happy.
...
Haskell also encourages you to shape the language to fit your problem domain, so the program often reads out like a runnable specification.

The bigger the language (syn)tax is, the bigger will be the distance to the Domain.
(read: you will have more syntax-noise in the code).
This "noise" can help you to understand the tehnology,
but it troubles you in understanding the domain.

That's why Smalltalk is good: very simple syntax. The rest is Domain Language.

[Errata, thanks to Tom Sattlers observation]
Smalltalk is no past tense.

IConvention

discussion.

snippets:
Get rid of the "I". Also you C++ programmers should get rid of the "m_" and you DAO fans should get rid of the DAO suffix. All these annotations put up a barrier to being able to "read" the code. When I read ICommand I feel like there is something missing, like I Command you to take out the garbage. When I see the C++ programmers "m_" I find myself humming while I read the code mmmmm counter, mmmmm index, mmmmm transmitter, mmmm window. Was the programmer really happy and humming, or were they confused and not sure what variable name to use? Probably the latter. Ohhh. a member variable, that is something special.

Well-written code (small classes, small methods, clear separation of responsibilities) has no need of Hungarian notation. What makes code readable is its approximation of natural language - Hungarian notation degrades that.

The second and bigger one is, the example you give is flawed. If you hose to turn your ICommand interface to a base class, then renaming isn't going to be the issue (as it can all be done by Resharper or equivalent in a few seconds at most). The problem is that many classes implementing your ICommand interface could now be very broken due to C# not supporting MI - so anything that has a base class already isn't going to work... and now you have a massive architectural nightmare.

Java has "extends" and "implements" which communicates very well on what the class inherits. C# doesn't have that, instead it uses the convention that if you inherit from more than one thing, the first must be a class and there can only be one class.

I think we have a mixture between:
- C# does not support multiple inheritance
- java's syntax is more explicit than C#'s
- The programmers need a language closed to the domain, (DSL),
the hungarian notation stays in the way.
- What we want is compiler-checked DuckTyping

I really want to learn Eiffel, to see if it delivers the answers, so shiny presented in
EiffelSoftware's presentations:
- multiple inheritance
- very close to Domain Language

The Humble Dialog Box

It looks like Michael Feathers "Humble Dialog Box" will make it into Martin Fowlers Patterns of Enterprise Application Architecture, 2nd. At least appears at "further development", here.

Here (and here) is a TDD sample for .Net, from Jeremy D. Miller.

UI Articles

on developerWorks, the cranky user series

a Set of Unit Testing Rules

From Michael Feathers weblog:

A test is not a unit test if:

It talks to the database

It communicates across the network

It touches the file system

It can't run at the same time as any of your other unit tests

You have to do special things to your environment (such as editing config files) to run it.

True, but communication to DB, over network, must also be Unit-Testable.
Probably a categorization fast/slow, partial/full, should also be done.

Michael answer to these points:

> Sometimes, your unit test must do some of these things:
> 1. You test a class who's function is to interact with a
> db, write/read a file, or write/read the Windows
> Registry.

I'm pig headed, I write them but I don't call them UTs when I'm with a team. Say that we are working test first and we discover we need to save things in the registry. To me it's best to think about what we need more abstractly, we just need a place to store things and chances are it doesn't need to be hierarchical in the beginning. So we can develop that abstraction (which probably looks as simple as a map) and it's guaranteed to be easier to use than the Windows registry.

If we go that route, we make an implementation of that abstraction that works in memory for testing and one that translates its calls to the Windows registry calls.

> 2. You develop a client; to make sure it works, it
> must interact with a server. At my work, for
> example, our client must exchange timestamped, signed, XML
> messages with a server. The test will not be complete
> without server interaction. Actually, you simply
> cannot test this without a server.
>
> You want to say these are not unit tests? I'll argue that
> the tests can't be any simpler.

I agree that they are necessary, but I really like to see what can be done to strip logic away from I/O for the UTs. Other tests can handle the collaboration and the tests that actually touch the database or the the server, they have tests too, but there are in some netherworld in my view. In general, I don't think there should be many of them.

I think that the main point is that we should use abstractions, "interfaces" in our program. It doesn't matter where the SmartObject.IsFunky gets his information, as long as he can answer the question "IsFunky". And this point of view should be seen in the UnitTests as well.

A new programming language every year

After Smalltalk, Eiffel.

cream on vim

Cream is a free and easy-to-use configuration of the powerful and famous Vim text editor
for both Microsoft Windows and GNU/Linux.

http://cream.sourceforge.net/

Xml Alternatives

for configurations files, or any situation, where a human is at one end of the communication line.

http://www.pault.com/pault/pxml/xmlalternatives.html

Personal preference:
JSON, PLists, Yaml.