http://sadache.tumblr.com

Jean-Laurent did a brief introduction to the talk on his blog.

“With the rise of web 2.0, Rest and Web Oriented Architecture emerged as inevitable solutions to today’s business challenges. However, to realize the benefits of this approach requires a comprehensive look at the whole model together with its composing technologies, design patterns and best practices. In this talk, we will go with you discovering this approach, highlighting its principal elements (standard Web technologies, linked data, Mashups…) helping you finding architecture values you care about in a dynamic, extremely extensible model, hoping you get an “AHA!” moment by the end of the day.”

If you’re a JavaScript hater, a SOA lord or a GWT geek come in to exchange with us on the differents views to solve a common problem

And yes there is one slide about functional programming with JS )

If you look at Haskell, Erlang, Scala and F#, what do you see? If you look at Haskell, you see something which, within its context, within the little framework it sets up for its sandbox, it’s very consistent, it’s very beautiful. You look at Erlang, it kind of fits, the bits fit together nicely. Of course, they don’t fit together nicely with the JVM or with .NET or anything like that. If you want to use all the nice things that are there, you can’t use them, or you can use them, but it’s difficult. So the other approach is, you say “Let’s use the JVM and target lots of different languages, so that the different languages can use each other” or you can do that within the .NET framework, you get Scala and you get F#.
The benefit there is you can use all these other things that are available, but in order to do them, you have to break them, massively corrupt and break these abstraction boundaries and I don’t like that. I think you are breaking abstraction boundaries in the wrong place. How I would like to see systems built is through communicating back boxes. And I would like to see the type systems applied to the definition of the protocols themselves and I haven’t seen that done.

                                                      Joe Armstrong from http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell

ps: reminds me of “And you get all the VM libraries for free! Is it actually what I want when I switch languages?“

Useability: Not just a pretty interface
Reflecting user’s model in code

Ergonomics and interface design are often approached as if all what they are about were a pretty GUI that hides the complexity of the underlying software. This is the reason why, even though the importance of this issue is well acknowledged, it is often treated at the later stages of the software development cycle, once modules and components are conceived and already developed. At this stage, achieving real productivity and usability becomes too costly and might require complete rewrite and recomposition of some modules. In this presentation, I will try to put the emphasis on the importance of considering interface design early in the development cycle, and provide insights into some practices that may be instrumental for creating better and simpler user interface, such as Domain driven design and user model mapping (reflecting the way user perceives software).

The LinQ Experience
Better expressiveness with less code

For a long time now, we’ve been failing, or at best not terribly succeeding, in achieving our ultimate dream of code reuse as a means for reducing code base and avoiding recurrent bugs. In the mainstream OOP approach, and even at the enterprise level, the idea of designing pluggable reusable modules doesn’t seem to work quite often. Having a potentially reusable component implies that it becomes more generic, requiring extra parameters and logic to satisfy more than one use case thus raising complexity level. Inspired from an already mature approach to functional programming, LinQ adopts a different approach to code reusability which operates rather at the micro level. It provides language constructs that allow functionalities to be composed of smaller functions (cells) that are themselves of composite nature.
Based on my experience from a recent real world enterprise project, I will provide you with insights and examples about adopting such an approach reviewing the consequences, pros and cons of this experience, showing how composability and reuse at the micro level can yield a more expressive code with fewer bugs.

Making the tough decisions early make the other decisions easier
To do agile you should be standing on a firm foundation
Stability != Static

YAGNI?  not extremely!
Fainting Ignorance :Don’t Play dumb! If you know some stuff celebrate that you know it and put a peg in the ground.
It is ok to know stuff, it is alright.

One of my childhood dreams was to have a time machine. A machine that can show me what will happen in the future. Thinking about it, this can be a huge opportunity of making money and fame. Bringing all the future inventions and innovations to the actuality will no doubt make you a hero.

Actually I won’t need a lot of years ahead, just enough that allows me to introduce a new concept or a new idea to a world that didn’t get to it yet. Of course there is credits and merits, but that idea did anyway have its value in its time (in the future), all what I will be doing is giving it yes more value and that is well rewarding for the idea itself.

No, I am not about science fiction here. We can almost predict the future without the need of a time machine. If we have a look at technology adoption, we can clearly see that, at least in IT, Europe is slightly behind the US. However there are countries (like my own) with a longer delay of adoption.In my opinion this is a huge opportunity of investment especially when we see with a simple observation how the technology adoption follows almost exactly the same steps, maybe with a faster rhythm, but with an considerable delay despite the wide spread of Internet and cheap communication. I guess the reason to that is that adoption should pass by the same stages of try and failure until it moves to the next level, rediscovering the wheel.

A company in the style of Y-Combinator that helps startups do shortcuts in these countries can be a good investment. Especially knowing that, in order to be integrated in the word’s economy, information should flow satisfying existing standard from the… future!

So, any investors?

http://www.infoq.com/news/2008/05/more-insights-static-vs-dynamic

The transcript of Steve Yegge’s presentation on dynamic languages in Stanford University, which he posted on his blog, triggered many reactions in the blog sphere. The transcript provides rather extensive insights into dynamic languages that Steve advocates for. According to him static languages have reached their limits and dynamic languages offer today comparatively more opportunities. Even though he acknowledges the existing issues with performance, maintainability and the lack of tooling, he believes they can be solved and what prevents dynamic languages from a more widespread use is rather the reluctance of the industry to use new languages.

Cedric Beust responded to Steve Yegge’s post to express his disagreement with many of Steve’s arguments and in particularly with his assertions that it is “not harder to build dynamic tools than for static languages, just different”:

It is different *and* harder (and in some cases, impossible). Your point regarding the fact that static refactoring doesn’t cover 100% of the cases is well taken, but it’s 1) darn close to 100% and 2) getting closer to it much faster than any dynamic tool ever could.

[…]

What will keep preventing dynamically typed languages from displacing statically typed ones in large scale software [] is the simple fact that it’s impossible to make sense of a giant ball of typeless source files, which causes automatic refactorings to be unreliable, hence hardly applicable, which in turn makes developers scared of refactoring.

There is one point however, Cedric and Steve seem to agree on even if they use different terms to explain it. Both believe that in today’s industry it is extremely difficult to introduce new languages on large scale development projects. Nevertheless, Ted Neward, who echoed at Steve’s and Cedric’s posts, disagrees with this observation. He argues that “the barriers to entry to create your own language have never been lower than today”. He recognizes “the cost of deploying a new platform into the IT.” Still, he believes that “there’s a lot of project work that goes on, that has room for some experimentation and experience-gathering before utilizing something on the next big project”. And such experimentation can be facilitated by making it possible to run the language on one of the available execution engines:

This is where running on top of one of the existing execution environments (the JVM or the CLR in particular) becomes so powerful–the actual deployment platform doesn’t change, and the IT guys remain more or less disconnected from the whole scenario. This is the principal advantage JRuby and IronPython and Jython and IronRuby will have over their native-interpreted counterparts.

To conclude Ted Neward says that “at the end of the day, the whole static-vs-dynamic thing […] doesn’t matter.” One should simply chose the languages that can :

1. Provide the ability to express the concept in your head, and
2. Provide the ability to evolve as the concepts in your head evolve”

Ola Bini’s reaction goes along the same lines, as he talks about polyglot programming. He believes that each kind of languages – strong static, weak static and dynamic – has advantages and downsides and that they are actually too different to be compared. One should use the language that offers features that fit the best the goal:

These languages are all useful, for different things. A good programmer uses his common sense to provide the best value possible. That includes choosing the best language for the job. If Ruby allows you to provide functionality 5 times faster than the equivalent functionality with Java, you need to think about whether this is acceptable or not. On the one hand, Java has IDEs that make maintainability easier, but with the Ruby codebase you will end up maintaining a fifth of the size of the Java code base. Is that trade off acceptable? In some cases yes, in some cases no. In many cases the best solution is a hybrid one.

According to Greg Young, the discussion on static vs dynamic languages should also take into consideration “the concept of static verification of more than just types” and he talks about opportunities offered by design by contract approach. He explains what the added value of using DbC is and suggests that static languages are more appropriate for it:

[…] it is reasonably easy with dynamic and static languages in general as can be illustrated by the existence of the DLR. There is however a much larger disconnect between the world of theorem proving and dynamic languages. Dynamic languages are in their definition runtime defined and static verification is in its definition compile-time defined, the use of a dynamic language makes the concept of statically verifying your code at compile time impossible. To try to verify dynamic code at compile time would likely walk you straight into the halting problem just like it would for many kinds of tooling.

Static verification and design by contract relay on theorems that are mostly based on deterministic approach. Steve Yegge has however argued in his presentation that verification can be done in a non-heuristic way exploiting the fact that “the runtime has all the information”. He uses the example of natural language processing and grammar checking to show that probabilistic approach may work a lot better and be computationally cheaper:

[… ]Microsoft Word’s grammar checker does it, where you’d have a Chomsky grammar. […] And you’re actually going in and you’re doing something like a compiler does, trying to derive the sentence structure. […]

None of that worked! It all became way too computationally expensive, plus the languages kept changing, and the idioms and all that. Instead, […] they [Google] do it all probablistically.

[…] you just obsoleted a decade of research by saying, "Well, we’re just gonna kind of wing it, probabilistically" — […] they get these big data sets of documents that have been translated, in a whole bunch of different languages, and they run a bunch of machine learning over it, and they can actually match your sentence in there to one with a high probability of it being this translation.

http://www.infoq.com/news/2008/04/special-purpose-chips

According to Moore’s Law, processors double in speed every 18 months. However, the new multicore trend resulted in a gap between the potential increase of speed and the ability of software to adapt to the multicore world and to exploit parallelism opportunities. In the aftermath of Intel’s announcement of their future six-core chip, Larry Dignan wonders "what exactly are we supposed to do with six cores when we have barely figured out what to do with four". 

Bearing this in mind, Bob Warfield suggests, in a recent blogpost, that rather than creating faster general purpose CPU, one could focus on designing new chip types that would have narrow specificity. This could have an important impact on the market structure, since the competitive advantage would not anymore lay within giants like Intel capable to create ever faster chips.  He mentions "special purpose chips built […] for maximum performance in various areas", e.g. graphics coprocessors or various network chips, and questions the interest that might bear the creation of special purpose chips optimized for running specific virtual machines.

He emphasizes that today "interpreted and scripting languages that are descendants of languages like Lisp and Smalltalk", e.g. Ruby on Rails, Python, and PHP are rather mainstream. And he recalls the observation of Alan Key that comparatively to old machines, like Dorado, "modern machines don’t run dynamic languages like Lisp and Smalltalk as much faster […] as their newfound clockspeeds would imply they should." Hence, Bob Warfield wonders whether creating special chips could allow these new mainstream languages, but also Java, to get faster:

Would a chip optimized to run the virtual machines of one of these languages without regard to compatibility with the old x86 world be able to run them a lot faster?  Would a chip that runs Java 10x faster than the fastest available cores from Intel be valuable at a time when Java has stopped getting faster via Moore’s Law?

Schedule – Wednesday

Schedule – Thursday

Schedule – Friday