step in english
This commit is contained in:
parent
fba96a0206
commit
b5496e1802
4 changed files with 130 additions and 30 deletions
|
@ -4,19 +4,22 @@ menupriority: 1
|
||||||
kind: article
|
kind: article
|
||||||
created_at: 2010-05-24T20:05:14+02:00
|
created_at: 2010-05-24T20:05:14+02:00
|
||||||
title: Trees; Pragmatism and Formalism
|
title: Trees; Pragmatism and Formalism
|
||||||
|
subtitle: When theory is more efficient than practice
|
||||||
author_name: Yann Esposito
|
author_name: Yann Esposito
|
||||||
author_uri: yannesposito.com
|
author_uri: yannesposito.com
|
||||||
tags:
|
tags:
|
||||||
- tree
|
- tree
|
||||||
|
- theory
|
||||||
|
- mathematics
|
||||||
-----
|
-----
|
||||||
# First: my experience
|
# First: my experience
|
||||||
|
|
||||||
It was said, 90% of programmer are unable to program a binary search without bug.
|
Apparently 90% of programmer are unable to program a binary search without bug.
|
||||||
The algorithm is well known and easy to understand.
|
The algorithm is well known and easy to understand.
|
||||||
However it is difficult to program it without any flaw.
|
However it is difficult to program it without any flaw.
|
||||||
I participated to [this contest](http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/).
|
I participated to [this contest](http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/).
|
||||||
And you can see the [results here](http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/)[^1].
|
And you can see the [results here](http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/)[^1].
|
||||||
I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform and <sc>xml</sc> into another <sc>xml</sc>.
|
I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform an <sc>xml</sc> from one format to another.
|
||||||
|
|
||||||
[^1]: Hopefully I am in the 10% who had given a bug free implementation.
|
[^1]: Hopefully I am in the 10% who had given a bug free implementation.
|
||||||
|
|
||||||
|
@ -65,17 +68,46 @@ And the destination format was in the following general format:
|
||||||
</menu>
|
</menu>
|
||||||
</code>
|
</code>
|
||||||
|
|
||||||
At first sight I believed it will not be so difficult. I had the following rules:
|
At first sight I believed it will be easy. I was so certain it will be easy that I fixed to myself the following rules:
|
||||||
|
|
||||||
* I don't want to use XSLT
|
1. do not use <sc>xslt</sc>
|
||||||
* I wanted to avoid <sc>xml</sc> parsor if possible
|
2. avoid the use of an <sc>xml</sc> parser
|
||||||
* I should do all that with a simple perl script wich search an replace things.
|
3. resolve the problem using a simple perl script[^2]
|
||||||
|
|
||||||
In the end, the program should be a simple list of:
|
You can try if you want. If you attack the problem directly opening an editor, I assure you, it will certainly be not so simple.
|
||||||
s/something/something else/g
|
I can tell that, because it's what I've done. And I must say I lost almost a complete day at work trying to resolve this. Each time, I made a try, each time I was close, but not on the solution. There was also, many small problems around that make me lose more than two days for this problem.
|
||||||
|
|
||||||
|
Why after two days did I was unable to resolve this problem which seems so simple?
|
||||||
|
|
||||||
|
What was my behaviour (workflow)?
|
||||||
|
|
||||||
|
1. Think
|
||||||
|
2. Write the program
|
||||||
|
3. Try the program
|
||||||
|
4. Verify the result
|
||||||
|
5. Found a bug
|
||||||
|
6. Resolve the bug
|
||||||
|
7. Go to the third step
|
||||||
|
|
||||||
|
And this is the *standard* workflow for computer engineer. The flaw came from the first step.
|
||||||
|
I thought about how to resolve the problem but with the eyes of a *pragmatic engineer*. I was saying:
|
||||||
|
|
||||||
|
> That should be a simple perl search and replace program.
|
||||||
|
> Let's begin to write code
|
||||||
|
|
||||||
|
This is the second sentence that was plainly wrong. Because of old external errors I started in the wrong direction. And the workflow did not work from this entry point.
|
||||||
|
|
||||||
|
Let's have a look at the *engineer workflow*. In fact, it is a simple algorithm which start from some point, and ameliorate himself at each step until it reach a solution. The key point is, you have a bad start, you can potentially never reach a solution point.
|
||||||
|
|
||||||
|
## spoiler
|
||||||
|
|
||||||
|
In the end, the program should be a simple list of search and replace:
|
||||||
|
<code>
|
||||||
|
s/something/something else/g
|
||||||
|
</code>
|
||||||
|
|
||||||
It is not only possible but I believe it is the best way of doing this.
|
It is not only possible but I believe it is the best way of doing this.
|
||||||
|
|
||||||
# conclusion
|
# conclusion
|
||||||
|
|
||||||
As it should seems a bit contractidory. Sometimes the most pragmatic approach to a pragmatic problem should be the theoretical one. Not the commonly accepted pragmatic one. This simple experience prove this point.
|
It should seems a bit paradoxal, but sometimes the most pragmatic approach to a pragmatic problem is to use the theoretical methodology. Not the commonly accepted pragmatic one. This simple experience prove this point.
|
||||||
|
|
|
@ -4,19 +4,22 @@ menupriority: 1
|
||||||
kind: article
|
kind: article
|
||||||
created_at: 2010-05-24T20:05:14+02:00
|
created_at: 2010-05-24T20:05:14+02:00
|
||||||
title: Arbres ; Pragmatisme et Formalisme
|
title: Arbres ; Pragmatisme et Formalisme
|
||||||
|
subtitle: Quand la théorie est plus pratique que la pratique
|
||||||
author_name: Yann Esposito
|
author_name: Yann Esposito
|
||||||
author_uri: yannesposito.com
|
author_uri: yannesposito.com
|
||||||
tags:
|
tags:
|
||||||
- arbre
|
- arbre
|
||||||
|
- théorie
|
||||||
|
- mathématiques
|
||||||
-----
|
-----
|
||||||
# First: my experience
|
# L'anecdote
|
||||||
|
|
||||||
It was said, 90% of programmer are unable to program a binary search without bug.
|
Apparently 90% of programmer are unable to program a binary search without bug.
|
||||||
The algorithm is well known and easy to understand.
|
The algorithm is well known and easy to understand.
|
||||||
However it is difficult to program it without any flaw.
|
However it is difficult to program it without any flaw.
|
||||||
I participated to [this contest](http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/).
|
I participated to [this contest](http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/).
|
||||||
And you can see the [results here](http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/)[^1].
|
And you can see the [results here](http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/)[^1].
|
||||||
I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform and <sc>xml</sc> into another <sc>xml</sc>.
|
I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform an <sc>xml</sc> from one format to another.
|
||||||
|
|
||||||
[^1]: Hopefully I am in the 10% who had given a bug free implementation.
|
[^1]: Hopefully I am in the 10% who had given a bug free implementation.
|
||||||
|
|
||||||
|
@ -65,17 +68,46 @@ And the destination format was in the following general format:
|
||||||
</menu>
|
</menu>
|
||||||
</code>
|
</code>
|
||||||
|
|
||||||
At first sight I believed it will not be so difficult. I had the following rules:
|
At first sight I believed it will be easy. I was so certain it will be easy that I fixed to myself the following rules:
|
||||||
|
|
||||||
* I don't want to use XSLT
|
1. do not use <sc>xslt</sc>
|
||||||
* I wanted to avoid <sc>xml</sc> parsor if possible
|
2. avoid the use of an <sc>xml</sc> parser
|
||||||
* I should do all that with a simple perl script wich search an replace things.
|
3. resolve the problem using a simple perl script[^2]
|
||||||
|
|
||||||
In the end, the program should be a simple list of:
|
You can try if you want. If you attack the problem directly opening an editor, I assure you, it will certainly be not so simple.
|
||||||
s/something/something else/g
|
I can tell that, because it's what I've done. And I must say I lost almost a complete day at work trying to resolve this. Each time, I made a try, each time I was close, but not on the solution. There was also, many small problems around that make me lose more than two days for this problem.
|
||||||
|
|
||||||
|
Why after two days did I was unable to resolve this problem which seems so simple?
|
||||||
|
|
||||||
|
What was my behaviour (workflow)?
|
||||||
|
|
||||||
|
1. Think
|
||||||
|
2. Write the program
|
||||||
|
3. Try the program
|
||||||
|
4. Verify the result
|
||||||
|
5. Found a bug
|
||||||
|
6. Resolve the bug
|
||||||
|
7. Go to the third step
|
||||||
|
|
||||||
|
And this is the *standard* workflow for computer engineer. The flaw came from the first step.
|
||||||
|
I thought about how to resolve the problem but with the eyes of a *pragmatic engineer*. I was saying:
|
||||||
|
|
||||||
|
> That should be a simple perl search and replace program.
|
||||||
|
> Let's begin to write code
|
||||||
|
|
||||||
|
This is the second sentence that was plainly wrong. Because of old external errors I started in the wrong direction. And the workflow did not work from this entry point.
|
||||||
|
|
||||||
|
Let's have a look at the *engineer workflow*. In fact, it is a simple algorithm which start from some point, and ameliorate himself at each step until it reach a solution. The key point is, you have a bad start, you can potentially never reach a solution point.
|
||||||
|
|
||||||
|
## spoiler
|
||||||
|
|
||||||
|
In the end, the program should be a simple list of search and replace:
|
||||||
|
<code>
|
||||||
|
s/something/something else/g
|
||||||
|
</code>
|
||||||
|
|
||||||
It is not only possible but I believe it is the best way of doing this.
|
It is not only possible but I believe it is the best way of doing this.
|
||||||
|
|
||||||
# conclusion
|
# conclusion
|
||||||
|
|
||||||
As it should seems a bit contractidory. Sometimes the most pragmatic approach to a pragmatic problem should be the theoretical one. Not the commonly accepted pragmatic one. This simple experience prove this point.
|
It should seems a bit paradoxal, but sometimes the most pragmatic approach to a pragmatic problem is to use the theoretical methodology. Not the commonly accepted pragmatic one. This simple experience prove this point.
|
||||||
|
|
|
@ -1 +1 @@
|
||||||
/Users/esposito/Sites/webroot/multi/blog/2010-05-24-Trees--Pragmatism-and-Formalism.md
|
multi/blog/2010-05-24-Trees--Pragmatism-and-Formalism.md
|
|
@ -4,21 +4,28 @@ menupriority: 1
|
||||||
kind: article
|
kind: article
|
||||||
created_at: 2010-05-24T20:05:14+02:00
|
created_at: 2010-05-24T20:05:14+02:00
|
||||||
fr: title: Arbres ; Pragmatisme et Formalisme
|
fr: title: Arbres ; Pragmatisme et Formalisme
|
||||||
|
fr: subtitle: Quand la théorie est plus pratique que la pratique
|
||||||
en: title: Trees; Pragmatism and Formalism
|
en: title: Trees; Pragmatism and Formalism
|
||||||
|
en: subtitle: When theory is more efficient than practice
|
||||||
author_name: Yann Esposito
|
author_name: Yann Esposito
|
||||||
author_uri: yannesposito.com
|
author_uri: yannesposito.com
|
||||||
tags:
|
tags:
|
||||||
en: - tree
|
en: - tree
|
||||||
|
en: - theory
|
||||||
|
en: - mathematics
|
||||||
fr: - arbre
|
fr: - arbre
|
||||||
|
fr: - théorie
|
||||||
|
fr: - mathématiques
|
||||||
-----
|
-----
|
||||||
# First: my experience
|
en: # First: my experience
|
||||||
|
fr: # L'anecdote
|
||||||
|
|
||||||
It was said, 90% of programmer are unable to program a binary search without bug.
|
Apparently 90% of programmer are unable to program a binary search without bug.
|
||||||
The algorithm is well known and easy to understand.
|
The algorithm is well known and easy to understand.
|
||||||
However it is difficult to program it without any flaw.
|
However it is difficult to program it without any flaw.
|
||||||
I participated to [this contest](http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/).
|
I participated to [this contest](http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/).
|
||||||
And you can see the [results here](http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/)[^1].
|
And you can see the [results here](http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/)[^1].
|
||||||
I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform and <sc>xml</sc> into another <sc>xml</sc>.
|
I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform an <sc>xml</sc> from one format to another.
|
||||||
|
|
||||||
[^1]: Hopefully I am in the 10% who had given a bug free implementation.
|
[^1]: Hopefully I am in the 10% who had given a bug free implementation.
|
||||||
|
|
||||||
|
@ -67,17 +74,46 @@ And the destination format was in the following general format:
|
||||||
</menu>
|
</menu>
|
||||||
</code>
|
</code>
|
||||||
|
|
||||||
At first sight I believed it will not be so difficult. I had the following rules:
|
At first sight I believed it will be easy. I was so certain it will be easy that I fixed to myself the following rules:
|
||||||
|
|
||||||
* I don't want to use XSLT
|
1. do not use <sc>xslt</sc>
|
||||||
* I wanted to avoid <sc>xml</sc> parsor if possible
|
2. avoid the use of an <sc>xml</sc> parser
|
||||||
* I should do all that with a simple perl script wich search an replace things.
|
3. resolve the problem using a simple perl script[^2]
|
||||||
|
|
||||||
In the end, the program should be a simple list of:
|
You can try if you want. If you attack the problem directly opening an editor, I assure you, it will certainly be not so simple.
|
||||||
s/something/something else/g
|
I can tell that, because it's what I've done. And I must say I lost almost a complete day at work trying to resolve this. Each time, I made a try, each time I was close, but not on the solution. There was also, many small problems around that make me lose more than two days for this problem.
|
||||||
|
|
||||||
|
Why after two days did I was unable to resolve this problem which seems so simple?
|
||||||
|
|
||||||
|
What was my behaviour (workflow)?
|
||||||
|
|
||||||
|
1. Think
|
||||||
|
2. Write the program
|
||||||
|
3. Try the program
|
||||||
|
4. Verify the result
|
||||||
|
5. Found a bug
|
||||||
|
6. Resolve the bug
|
||||||
|
7. Go to the third step
|
||||||
|
|
||||||
|
And this is the *standard* workflow for computer engineer. The flaw came from the first step.
|
||||||
|
I thought about how to resolve the problem but with the eyes of a *pragmatic engineer*. I was saying:
|
||||||
|
|
||||||
|
> That should be a simple perl search and replace program.
|
||||||
|
> Let's begin to write code
|
||||||
|
|
||||||
|
This is the second sentence that was plainly wrong. Because of old external errors I started in the wrong direction. And the workflow did not work from this entry point.
|
||||||
|
|
||||||
|
Let's have a look at the *engineer workflow*. In fact, it is a simple algorithm which start from some point, and ameliorate himself at each step until it reach a solution. The key point is, you have a bad start, you can potentially never reach a solution point.
|
||||||
|
|
||||||
|
## spoiler
|
||||||
|
|
||||||
|
In the end, the program should be a simple list of search and replace:
|
||||||
|
<code>
|
||||||
|
s/something/something else/g
|
||||||
|
</code>
|
||||||
|
|
||||||
It is not only possible but I believe it is the best way of doing this.
|
It is not only possible but I believe it is the best way of doing this.
|
||||||
|
|
||||||
# conclusion
|
# conclusion
|
||||||
|
|
||||||
As it should seems a bit contractidory. Sometimes the most pragmatic approach to a pragmatic problem should be the theoretical one. Not the commonly accepted pragmatic one. This simple experience prove this point.
|
It should seems a bit paradoxal, but sometimes the most pragmatic approach to a pragmatic problem is to use the theoretical methodology. Not the commonly accepted pragmatic one. This simple experience prove this point.
|
||||||
|
|
Loading…
Reference in a new issue