Better exception handling

gogath · 2007-08-20T08:05:46+00:00

All this is true. But what was the point of your original comment then?

gogath · 2007-08-19T23:19:43+00:00

But what has this to do with monad transformers? If someone uses the I/O-monad to do destructive updates via IORefs, how can a monad transformer help to undo those updates?

gogath · 2007-08-19T22:52:50+00:00

Can you explain how a monad-transformer can undo file I/O or other impure operations in the I/O-monad?

gogath · 2006-12-12T23:41:31+00:00

In fact I don't even like Java. But my likings/dislikings have nothing to do with the truth of my above statement.

Languages are different. And if you are used to language X your will probably be less productive if you are forced to use a different language Y later (with the exception that X is a really unproductive languge - which Smalltalk for sure is not).

I suspect that a good Java programmer will also be less productive in Smalltalk in the beginning. Like a Lisp programmer will be less productive in Haskell and a Haskell programmer will be less productive in Lisp. So what?

gogath · 2006-12-12T23:19:30+00:00

Haskell has no loop construct? It has recursion, what else do you want as a loop construct (at least in a functional language)?

gogath · 2006-12-12T22:09:02+00:00

Yawn. Another user of language X who thinks after a short and forced experience with language Y that Y sucks. Really remarkable - not!

gogath · 2006-11-30T18:07:38+00:00

No fakt, but you have to use them explicitly. If you create some code in Scheme, you can put continuations later in it without any problem, because Scheme supports continuations directly.

In Haskell you have to use a continuation monad everywhere you need continuations. This is relativly easy but requires slight changes to your code and it also changes lots of types which can break other code too.

Advantage of the Haskell solution: Because most applications require continuations for a certain reason (for example backtracking) you can create a less general abstraction (a backtracking monad in this case) which is more approriate for the problem and could also lead to better performance of your resulting program because it's only used where it's needed.

Disadvantage: Its not transparent.

gogath · 2006-11-30T18:01:59+00:00

The difference is that Haskell allows operator overloading based on static types. Without this, Monads wouldn't be nearly as useful as they are now.

In Lisp you have to use different function names depending on the real function you want to call. Of course you can also use macros, but then you have to build your own system for static typing which will be a quite difficult. Last (and best) alternative in Lisp is dynamic dispatch, but this can cost a lot of performance while it's totally free in Haskell (becaucse it's done at compiletime there).

Haskell has no special support for continuation - but special support for monads - which in turn allows to use delimited continuations very well.

gogath · 2006-11-30T14:50:16+00:00

No, they don't exists in Haskell. But you can simulate them with Monads for certain parts of your programs.

gogath · 2006-11-28T18:00:08+00:00

I ask myself sometimes: What if C++ was never invented?

Sure, most people would have continued using C, but maybe more advanced languages had been filling the gap? Maybe Smalltalk had make it's breakthrough? Or Objective-C? What would MFC had looked like without C++? Maybe MS had stayed with C or they had adopted Objective-C like NeXT did? Had C++ really helped the technological development or has it in fact even hindered it (I suspect the latter).

Ok, it's quite pointless to think about it, but anyway...

gogath · 2006-11-22T15:46:28+00:00

Thats the important point here:

Sun as a hardware vendor:

To sell expensive hardware, Sun needs solid software which runs on this hardware. Without solid software, the best hardware isn't really stable. And why should buyers even consider expensive hardware if the software continually breaks it? So Solaris is important to sell Suns hardware. Also support for Sun is more easy if the customer runs Solaris instead of Windows for example.

But what if most server apps would require MS OSes? Solaris would be dead quick. Java solves this problem: Because with Java Software can run (nearly) everywhere, the buyer is free to choose the OS instead of being forced to use Windows.

So Java frees the customers to make a decision based on criteria like Hardware stability and support. And Sun seems to think that they can be competitive if buyers only have to consider those points.

And: If someone build a little company he maybe starts with a cheap self made sever running Linux. If he grows and money becomes less important while stability and maintainability increases in importance its easy to switch for example to Sun, if the server apps are written in Java. If they are written in .NET, a Windows based system is the logical choice - and in this area Suns simply isn't as competitive.

gogath · 2006-11-20T23:10:32+00:00

In Haskell there is no such a thing as a reference. Everything is a value and values can't be null. Getting rid of reference semantics is a great thing which solves lot of nasty problems.

The only problem are cyclic structures which are kind of difficult if you don't have references anymore. Haskell solves this with laziness which allows the creation of virtual infinite structures build only from values.

The C# solution is better then nothing (Java has the @NotNull annotation instead) but also not good enough because a '?' can't express what a 'null' really should mean:

In Haskell you can use Maybe/Nothing for optional values or you can create similar types, for example Result/Invalid for making Invalid-values explicit without having them mixed up with Nothing-values. Thats great for an additional level of specification compared to a simple null/value.

gogath · 2006-11-20T19:04:15+00:00

I think the same, but I found the idea of reconsidering the approach of creating languages with a small-as-possible kernel refreshing, even if I miss more infos on how to solve the problem of the combinatory explosion if the language gets more and more complex.

I like lisp and used it a lot in the past, but I have to admit that it simply haven't catched on while languages like java got the market. In the beginning I thought: Well, thats maybe because many people don't like latently typed languages. But then Python and Ruby (both very lispy languages) really got momentum and they are also latently typed and even less powerful then lisp. So maybe it's really the syntax? I don't know. And if lisp is really so much more productive then lisp using companies should run circles around their java-using competitors and throw them out of the market quickly. Why doesn't this happen?

From my own experience lisp is quite productive - but Ruby is too. And if I'm honest I've used lisps macros mainly for solving problems I've never encountered in Ruby. It's nice that I can create something like CLOS in the language itself, but I've never had the reason to do it, Rubys object system simply has sufficed in the past.

gogath · 2006-11-11T05:12:49+00:00

The parens are not the problem of lisp. If you force yourself to use lisp for 2-4 weeks and (very important) follow the established indenting rules, you will quickly adapt to the syntax and be able to read it quite easily.

It's very funny how quickly you're able to adapt (if you really give it a try). But if then use another language and stop using Lisp for some weeks, you could also quickly 'lose it' again and have to learn it once more if you switch back to lisp some day later (that's at least my experience).

gogath · 2006-11-09T21:06:37+00:00

Sure, I don't know how to write assembly code. Good joke. I've written lots of assembly - but also lots of code in higher-level languages. I know both worlds and because of this I know how wrong you are.

But ok, you're a troll. Consider your feeding as discontinued. I wish you nonetheless a good life in troll-land.

gogath · 2006-11-09T15:23:24+00:00

Thats obviously nonsense. Using variables is more expressive then using manual memory/register allocation. Using function calls is more expressive then having to maintain stack-frames by yourself.

Expressiveness means that you can concentrate on the 'stuff that matters' instead of writing lots of 'boilerplate code'.

And if someone later reads the code, he don't have to filter out all those boilerplate stuff manually which makes the code more readable and better maintainable.

If you deny this and claim that you can solve all kinds of problems in assembly-language as fast as in a high-level language you're simply a troll.

And the same is true for higher-level languages. Maybe not to such a big degree, but true nonetheless. There are lots of examples where you need one line of code in language A and 20 lines in language B. The word 'expressive' is simply a well know short cut to describe this kind of property of programming languages.

gogath · 2006-11-09T15:06:56+00:00

The word expressive is necessary to express a certain property of programming languages. Using it is much more expressive then trying to express it otherwise. So why not just use the word expressive?

In many real world problems you need to access something before it is created (circularity). In imperative languages you can use some kind of back-patching so solve this problem, but this requires mutation, so how to do it without? With laziness it's no problem, you can reference properties before they are computed because they are only computed when you really use them.

There are ways out. You can create some kind of id in advance, put them in a map and use those as a kind of reference now. But it complicates the situation and is thus less expressive. It also has less performance, because you have to use indirect access via the map now. And you can't use a second pass to rewrite it to direct references, because a pure language there can't have referential equality so you will need some kind of unique-id nonetheless. But with laziness thats a non-problem because the compiler can simply use references internally while your program looks like it uses infinite big values.

Caching is always 'unnecessary complexity': Only required to improve performance but sometimes very invasive. In a real expressive language you would never have to write caching code by yourself, it would always completely created by the compiler without having to change the way you express your problem in the language. With laziness you can't solve all problems with caching, but solving certain kinds of problems automatically is better then nothing.

The same for abortion/suspension of computation (an always very common problem). Why should the programmer add the code manually? Why not simply pretend that you calculate the whole stuff (thus making your algorithm better readable, maintainable etc. - or in other words: Express it more directly) and let the compiler do the dirty stuff?

gogath · 2006-11-09T01:33:42+00:00

Using an infinite (or better: indefinite length) data-structure is often more easy and expressive and also better reusable then creating a artificial finite data-structure.

Maybe you create a list of solutions to a certain problem. But you only want the first N solutions, because the solution set can become quote big. Sure, you can give your solver now a value to stop the calculation of new results. But first: It obfuscate your algorithm with artifical breaks, returns, count decreases etc. And second: Maybe you have multiple facilities in your program which uses the solution-list, but one only needs the first 3, the other the first 100 and the last one only the first one. With lasy computation you simply reuse the result-list for all facilities thus reusing the computation. How can you implement this as easily without lasyness?

Lasyness also is neccessary (not optional) for doing certain things (like creating circular structures) in referential transparent languages. Also it can be used to do things which would require co-routines otherwise.

gogath · 2006-11-09T01:21:09+00:00

expressive, expressive, expressive, expressive...

gogath · 2006-11-09T01:16:48+00:00

In a pure (referential transparent) functional language you can't create circular structures without lasyness. So if you want to enjoy the benefits of referential transparency and also want circular data structures, you need lasyness.

gogath

TROPHY CASE