On Fri, Oct 3, 2008 at 5:47 AM, Dougal Stanton wrote:

2008/10/3 Galchin, Vasili :

...

Hello,

One of my interests based on my education is "grand challenge science". Ok .. let's take the CERN Hadrian Accelerator.

Where do you think Haskell can fit into the CERN Hadrian effort currently?

Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian?

Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-)

I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something).

Well, with the LHC efforts I don't think a technology like Haskell really has a place...at least not now. Even just a few years back, when I worked on this stuff, we were still doing lots of simulation in preparation for the actual live experiment and Haskell might have been a good choice for some of the tools. All of the detector simulation was written in C++, because C++ is the new FORTRAN to physicists, and you ain't seen nothing till you've seen a jury-rigged form of lazy evaluation built into a class hierarchy in C++. Now, would the C++ based simulation have run faster than a Haskell based one? Quite possibly. On the other hand, I remember how many delays and problems were caused by the sheer complexity of the codebase. That's where a more modern programming language might have been extremely helpful.

On Fri, Oct 3, 2008 at 2:38 PM, Don Stewart wrote:

wchogg:

...

On Fri, Oct 3, 2008 at 5:47 AM, Dougal Stanton wrote:

...

2008/10/3 Galchin, Vasili :

...

Hello,

One of my interests based on my education is "grand challenge science". Ok .. let's take the CERN Hadrian Accelerator.

Where do you think Haskell can fit into the CERN Hadrian effort currently?

Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian?

Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-)

I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something).

Well, with the LHC efforts I don't think a technology like Haskell really has a place...at least not now. Even just a few years back, when I worked on this stuff, we were still doing lots of simulation in preparation for the actual live experiment and Haskell might have been a good choice for some of the tools. All of the detector simulation was written in C++, because C++ is the new FORTRAN to physicists, and you ain't seen nothing till you've seen a jury-rigged form of lazy evaluation built into a class hierarchy in C++. Now, would the C++ based simulation have run faster than a Haskell based one? Quite possibly. On the other hand, I remember how many delays and problems were caused by the sheer complexity of the codebase. That's where a more modern programming language might have been extremely helpful.

How about EDSLs for producing high assurance controllers, and other robust devices they might need. I imagine the LHC has a good need for verified software components...

^^ totally agree on the "verified" Don. Don, by controller do you mean an I/O controller?? Vasili

On Fri, Oct 3, 2008 at 6:39 PM, wrote:

G'day all.

Quoting Don Stewart :

How about EDSLs for producing high assurance controllers, and other

...

robust devices they might need. I imagine the LHC has a good need for verified software components...

On a related topic, I'm curious if anyone apart from me has been secretly using Haskell for model-driven-development-lite.

My current boss, not being a programmer, doesn't care where the code comes from, so the following conversation is unlikely to happen. Still. other people must also have thought of doing this:

"Well, the reason why I've produced so much C++ lately is because I've been generating all the boilerplate automatically. What with? Glad you asked..."

Replace C++ with python and you have what I've been thinking about. I've been of several minds: 1) Write a type checker for python in Haskell 2) Write a Haskell program that reads special "type" comments from python programs and type checks the python 3) Write a python generating EDSL in Haskell 4) Translate Haskell to python Python is what we typically use for various technical reasons, but I'm quite unsatisfied with it. Every time I turn around I'm faced with learning a new facet of the language (or less politely, a limitation it has that I wasn't expecting). I also find that I spend a lot of time trying to figure out ways to hit the various control paths, otherwise I rely on tools like pylint, which don't work so well. When, I'm often just looking for type incorrect statements and misspelled variable names. Really, if I had more static analysis, I'd have to do less of what the compiler could be doing. I think testing is often easier in Haskell too, but maybe that's just my opinion. The problem with #1 is that others have tried it, python just doesn't lend itself to type checking. The problem with #2 is that I'm no longer writing python, I'm writing my version of python and other devs on our team could object, and some of the problems with #1 may apply. None of those are strong arguements against it. The main problem with #3, is that if I share code with other devs they have to learn Haskell and my EDSL since they won't be able to just hack the generated python, similar problem with #4. Also, problem with #4 is that it may be difficult to generate efficient idomatic python code. At my company, the source code is often a deliverable it seems that I can really only do #1 and #2 and I'm not convinced it's worth the effort. I'd probably better off making a tool that can read in a python program and generate test cases to correspond to the work that static analysis would be doing. This is the first time this idea has occured to me, but I like it and I should spend some more time thinking about it. Is it possible to make a test case generator that can generate test cases to hit each execution branch in a program? Oh, but maybe I could use such a program to solve the halting problem? If so, that would be a useful application as well :) Fundamentally, I think I agree with your approach assuming the political and team aspects work out. If you're the only one that is willing to use language X on the team then it seems like bad form to use language X when you know you have a team to work with. Sometimes being a team player is way more important than the technical details, or so I've found. Jason

Gents Too late to get in on that act - that software was designed over the last 10/15 years implemented and trailed over the last 5 and being tuned now. But all is not lost, Haskell is being used! Well in least in helping ATLAS people understand how to the data acquisition system performs (and interacts) - its what the stochastic performance algebra language being used to capture behavioural models is written in. Neil On 3 Oct 2008, at 20:38, Don Stewart wrote:

wchogg:

...

On Fri, Oct 3, 2008 at 5:47 AM, Dougal Stanton

...

wrote: 2008/10/3 Galchin, Vasili :

...

Hello,

One of my interests based on my education is "grand challenge science". Ok .. let's take the CERN Hadrian Accelerator.

Where do you think Haskell can fit into the CERN Hadrian effort currently?

Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian?

Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-)

I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something).

Well, with the LHC efforts I don't think a technology like Haskell really has a place...at least not now. Even just a few years back, when I worked on this stuff, we were still doing lots of simulation in preparation for the actual live experiment and Haskell might have been a good choice for some of the tools. All of the detector simulation was written in C++, because C++ is the new FORTRAN to physicists, and you ain't seen nothing till you've seen a jury-rigged form of lazy evaluation built into a class hierarchy in C++. Now, would the C++ based simulation have run faster than a Haskell based one? Quite possibly. On the other hand, I remember how many delays and problems were caused by the sheer complexity of the codebase. That's where a more modern programming language might have been extremely helpful.

How about EDSLs for producing high assurance controllers, and other robust devices they might need. I imagine the LHC has a good need for verified software components... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

"...gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place..." Sounds like a good application for lazy evaluation! (Actually, they may have to read over it all to make sure they can throw it away...) On Fri, Oct 3, 2008 at 6:47 AM, Dougal Stanton wrote:

2008/10/3 Galchin, Vasili :

...

Hello,

One of my interests based on my education is "grand challenge science". Ok .. let's take the CERN Hadrian Accelerator.

Where do you think Haskell can fit into the CERN Hadrian effort currently?

Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian?

Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-)

I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something).

Cheers,

D _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /jve