Windows refound if when you buy a computer
Minds are evolving...
Personal stuff. Obviously.
Posted by Fanf at 17:30 0 comments
Here we are, Scala 2.7.2 was released on november, the 10.
And it's a great news !
You may wonder why a minor release seems to be so important ?
C'm'on, it's a palindromic release number, it's so fantastic !
Well, more seriously, it's because this released is the one that will be cover by the coming book "Programming in Scala", and so, this release mark a kind of shift in the Scala language development : Until now, the language was evolving quite quickly, what was great in term of enhancement, but bring some recurring problems, and seems to frighten a lot "the enterprise developers" (or at least there bosses).
With this release, seconded by a great book, the Scala language reach a new level of maturity, and perhaps will gain more visibility outside the rather small (but growing !) circle of first time enthusiastic who use it today.
So, it's a great news for Scala users, and a great time to go and discover Scala !
Posted by Fanf at 09:19 0 comments
I'm still playing with project Euler, and I'm going to love Scala more and more.
Yesterday, I solved the #42 problem, on which we need to parse a text file, and make some simple transformations and filtering on the results (it's why I choose this title, because it's generally the kind of things you expect to do in a scripting language, and well, I'm really
impressive, and I read this morning the post "Scala as a scripting language?", and I say "ho, it's exactly what I felt when I did pb#42 yesterday, let's blog on it, it's fashion :)
So, this problem is a simple Project Euler one (at least, there is no math on it), but just stop and think to what may look the Java's solution. Yes, you will have to deal with Files, input stream, and the like, filtering data, sorting things, and even if it's quite simple, it's always a little too heavy compared to what it may be.
So, there is the full solution in Scala, in a mixed imperative and functional style, as produced in the first sketch version (OK, I'm lying, in the first sketch, I didn't include comments and variables names looked more to 'lsv' and the like, these transformations are blog add-ons).
I'm sure there is a lot of optimizations available, but the important think is that Scala let you program as you think, whitout to much noise and boilerplate...
So let's go for the code:
package ex26_50
import scala.io.Source
/*
Problem#42
The nth term of the sequence of triangle numbers
is given by, tn = n(n+1);
so the first ten triangle numbers are:
1, 3, 6, 10, 15, 21, 28, 36, 45, 55, ...
By converting each letter in a word to a number corresponding to its
alphabetical position and adding these values we form a word value.
For example, the word value for SKY is 19 + 11 + 25 = 55 = t10.
If the word value is a triangle number then we shall
call the word a triangle word.
Using words.txt (right click and 'Save Link/Target As...'),
a 16K text file containing nearly two-thousand common English
words, how many are triangle words?
*/
object Problem42 extends Application {
/*
* iterate over all the lines of a file and
* split each one on ',', remove surronding ",
* and put the result in a list
*/
def parseWords(file:String): List[String] = {
for {
line <- Source.fromFile(file).getLines.toList
s <- line.split(",")
if(!s.isEmpty)
} yield s.replaceAll("\"","")
}
/*
* Simple mapping function that associate
* each char to it's value (position in the alphabet, begin to 1)
* and a word to the sum of its char value
*/
def wordValue(s:String) : Int = {
var sum = 0
for(c <- s) {
// iterate over the chars of the string
val cval = c.toInt
if(cval >= 64 && cval <= 90) {
// 64 = ascii val for 'A', 90 = ascii val for 'Z'
sum = sum + cval - 64
} else {
error("Unauthorized char: " + c.toString)
}
}
sum
}
/*
* That's the definition of the list number on witch we will work:
* - parse the file to a list of word
* - transform each word to it's word value
* - sort the resulting, so that we can know the
* upper bound of our triangle value to caluculate
*/
val list_wordValues =
parseWords("src/words.txt").map(wordValue(_)).sort(_ > _)
//we also see that in Scala, Format syntax is actually usable
println("Max value in %s words: %s (min: %s)".format(
list_wordValues.size,
list_wordValues.head,
list_wordValues.reverse.head))
/*
* Given the upper bound,
* generate the set of triangle number
*/
val set_triangles = {
var set = Set[Int]()
var n = 1
var i = 1
while (n < max ) {
n = (i * (i+1))/2
i = i + 1
set = set.+(n)
}
set
}
/*
* That's all, we just have to filter the list of words to
* only keep whose which are in the set of triangles value,
* and take the size of the resulting list.
*/
val nb = list_wordValues.filter( (i:Int) =>
set_triangles.contains(i)).size
println("Found %s triangles words !".format(nb))
}
Posted by Fanf at 10:21 2 comments
Labels: project euler, scala, shjs
I'm a "static typed languages" guy. Whose who know me see what I mean :)
The Rail's boys would say it's because I'm frightened by the field of possibilities, the freedom of dynamic languages [1]. I believe that it's more certainly because I came to software development through OCaml, a really good static typed language, and not like a vast majority of developer through languages from the C family (Java the worst among them [2]), which really missed the point of most of the advantages of static typing (yes, one days I will write about how enlightening was my experience with the Coq Proof assistant, and why things like FPH are beautiful)
So, because I'm dealing with Javascript, Pearl, Ruby and Python fan boys quite often (Lisper and Smaltalker are somewhat rarer ;), I would highlight this really good article about static and dynamic type systems, and the fallacies that most programmers believe about statically typed language : http://www.pphsg.org/cdsmith/types.html.
Synopsis:
Fallacies About Static and Dynamic Types
Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven't tried a lot of languages. For context, here, six or seven doesn't count as "a lot." On top of that, it requires more than a cursory glance to really see the benefit of these two very different styles of programming. Two interesting consequences of this are:
- Many programmers have used very poor statically typed languages.
- Many programmers have used dynamically typed languages very poorly.
This section, then, brings up some of the consequences of this limited experience: things many people assume about static or dynamic typing that just ain't so.
Posted by Fanf at 08:57 0 comments
Thuesday the 7 october, I met Howard Lewis Ship, the father of Tapestry 5 Java web framework in Paris.
He was here for a 3 weeks trip in Europe, far from its home, Portland, USA.
There were Howard, his wife Suzan, and almost all my developers team, so 5 people from Linagora, all of them T5 addicts.
Evening part I : bar and T5
Imminent release of 5.0 final....
The evening began with a beer (or two...) in a bar near Linagora, and the discussion almost immediately started on Tapestry 5. Howard wanted to know how we came to T5, so I explained that I'm following its development since 5.0.1 and that I didn't chose at all by luck T5. Now, every developer in my team use T5, and quite like it.
We chatted about the iminent release of T5.0 final (YES !), the beauty of the framework thanks to the IoC framework, its scalabity, not only in performance, but in all thinkable meaning of the term : scalabitly in component from technical ones to business ones, scalabilty of the T5 user target from the business oriented people to the the technical nerd, etc.
We also discussed the missing points, around the documentation and some little things (what bring me to a ml post on the subject).
... and Tapestry 5.1 project...
The discussion followed on the 5.1 release, it's short, time-based and not functionnality-based release cycle, every 3 to max 5 month.
I think this is a really good new, because it was one of the most recurrent criticism against Tapestry : its really really long release cycle, along with the compatibility issue between them. Even if Howard came back several times on the last point (it's even explained in the T5 home page, at the bottom), upgrades would be even smoother if there is less time between them. Moreover, from a customer point of view, it's always best to have his product based on a stable release. I mean, a release tagged stable, because T5 is already one of the most stable soft I used, but the "alpha" or "beta" status is something quite frightening for a customer...
Afterwards, Howard gives us the possibility to argue for our "most wanted feature".
This is our wish-list, along with what Howard expects :
Posted by Fanf at 09:35 0 comments
Labels: meeting, open source, tapestry 5
© Blogger template 'Minimalist G' by Ourblogtemplates.com 2008
Back to TOP