Laser panel

Laser finished today with a panel, in which participants can ask the speakers questions.

To Erik: Did you predict the collisions of imperical and function styles in C# that you talked about in your first talk?

No, coming from functional programming I did not see those problems. I think the way to go is to start functional and add effects, because it is too hard to start with side effects and then tame them.

For Andrei: Do you agree, is starting functional really the way to go?

Andrei states that from his experience with D, mutation is also a good starting points. Erik responds that it is not just about mutation, there are other side effects too. Guido says it is not really fair to compare D and C#, since when C# started changing their model when they already had a lot of users.

A participant says that this is a question of courage, you should just change if you feel this is better. Erik disagrees and says that many instances of code reuse are copy-pasted and it is impossible to update all those websites. Guido adds that in that case it could be better to make a new language.

To Simon: Can we compile arbitraty languages to FC, Python for instance?

Python will be extremely hard, since FC is strongly typed. As always the intermediate language is very tied to the base language, so problably not.

What programming language is your favorite, besides your own?

Erik: JavaScript
Guido: C
Andrei: Haskell

What is it that makes a language take off?

Robarto answers immediately: Luck. Andrei adds: Java did not have luck, it had a billion dollars. Erik mentions that there is a recent paper by researchers from Berkeley on the success factors. Simon adds that you need a “hook” something that is distinctive, that could possibly gives someone a reason to start.

Many people in industry use Java, it seems to be the state of the art. If you were the CEO of such a company, what language would you choose?

Erik answers: why not use a language that compiles to the JVM, like Scala or Clojure “Your boss won’t even see the difference”

How do you decide whether a new feature ends up in your language?

Guido: In Python for a new feature, one has to write a Python Improvement Proposal. You would try that if the writer of such a proposal does a good job, it gets accepted, but it is not that easy. Many die since they would only benefit a small group of users, the most features that are accepted benefit a large group of Python users. You should not focus on non-Python users, says Guido, they will find a new reason not to use your language.

Andrei adds that you should not be asking “why not” you should be asking “why”. Roberto agrees and says that it is not about the cost of implementation, but of the cost of explanation: how more complex do you want to make your language. Also: think about conflicts with possible future functions, so think about what adding this feature will prevent.

Erik summarizes: “A programming language is like a monad, when you put something in, it can never get out”

Microsft added xml support to VB6  (“when nobody even remembers what XML is”) the feature stays in.

Bertrand Meyer asks: in the world where languages are merging, what real programming languages principles remain?

Erik answers that it is a good thing that languages take each others features, since they are more similar than dissimilar. Guido adds that in the 80s writing a language was very much about figuring out how to create a compiler for the language and this is now (more or less) a solved problem. So now we can focus on the users: what do they want, how can we help them to be better able to write the software they need? Maybe they need speed and not safety, then one language is better than another.

Erik: do you look at C# sometimes and make functions deprecated?

This is like trying to convert Americans to the metric system. It will never happen. Yes, C# is a bit messy, but the price you pay for a language that is a little bit cleaner is much higher.