Kategorie: Allgemein

Die Weißenoher Klosterbrauerei ist ja ein Name, der für gutes Bier steht. So gesehen überrascht es auch nicht, dass das Eucharius Pils ein leckeres kräftig gehopftes Pilsener ist. Alles richtig gemacht! 

    
 

Die Weißenoher Klosterbrauerei ist ja ein Name, der für gutes Bier steht. So gesehen überrascht es auch nicht, dass das Eucharius Pils ein leckeres kräftig gehopftes Pilsener ist. Alles richtig...

Mann ist das fruchtig! Quasi ein Smoothie für den passionierten Hefetrinker. Das sollte man mal probiert haben. Allerdings hat’s die Konkurrenz danach extra schwer.

   

 

Mann ist das fruchtig! Quasi ein Smoothie für den passionierten Hefetrinker. Das sollte man mal probiert haben. Allerdings hat’s die Konkurrenz danach extra schwer.      

Sehr malziges Münchener Hell mit vernehmlicher Hopfennote. Nicht das allerletzte Abgeschnakelte überhaupt aber auch nicht verkehrt. 

   

   

Sehr malziges Münchener Hell mit vernehmlicher Hopfennote. Nicht das allerletzte Abgeschnakelte überhaupt aber auch nicht verkehrt.         

Diese perfekte Balance zwischen Hopfen und Malz hinzubekommen, das ist ja das eigentlich Schwierige bei der Braukunst. Die Meckatzer schaffen das. Untenrum runde Malznoten mit leichter Dunkelmalzigkeit, obenrum frische Hopfenprickelung. Da möchte man eigentlich mehr von trinken, aber bei 5,4% merkt man schon nach der ersten Flasche, dass man damit vorsichtig sein muss. Nur etwas für die richtig guten Feste!

Vielen Dank an @insanelygreat, der mir diesen Tropfen in die Inbox gestellt hat!

Diese perfekte Balance zwischen Hopfen und Malz hinzubekommen, das ist ja das eigentlich Schwierige bei der Braukunst. Die Meckatzer schaffen das. Untenrum runde Malznoten mit leichter Dunkelmalzigkeit, obenrum frische Hopfenprickelung....

Thailand ist nicht als Bierbraunation bekannt, oder? Dementsprechend waren meine Erwartungen nicht sehr hoch. Aber es ist ganz Ok. In der Flasche findet man ein sehr mildes fruchtiges Bier, das deutlich mehr Hopfen vertragen könnte. Für einen passionierten Pilstrinker ist es also definitiv nichts, für alle Anderen, nun ja… das mitteleuropäische Bierangebot lässt dem Chan eigentlich wenig Luft außerhalb der Exotenrolle. Aber hey, eventuell ist es in Thailand das Getränk der Wahl.

Thailand ist nicht als Bierbraunation bekannt, oder? Dementsprechend waren meine Erwartungen nicht sehr hoch. Aber es ist ganz Ok. In der Flasche findet man ein sehr mildes fruchtiges Bier, das...

Ich würde ja „dunkel“ draufschreiben. Aber was soll das, schließlich könnte man die Flasche genauso gut mit „lecker“ beschriften. Oder mit „nicht an diesem Bier vorbeigehen!“. Aber die fränkischen Brauer sind ja bescheiden. Und die aus Unterzaunsbach tun viel leckeres Malz ins Bier!

Ich würde ja „dunkel“ draufschreiben. Aber was soll das, schließlich könnte man die Flasche genauso gut mit „lecker“ beschriften. Oder mit „nicht an diesem Bier vorbeigehen!“. Aber die fränkischen Brauer...

Da sprudeln die Aromen! Viel Malz und die typisch belgische Brettanomyceshefe (nehme ich an, wer weiß?). Dazu eine leichte Süße und schon ist man froh, dass nur 0,3l in der Flasche sind. Sonst könnte das bei den 6,6% Vol. böse enden.

P.S.: ich wünsche mir eine Rückbesinnung auf solche Biere statt (wie die Amerikaner derzeit) einfach nur brutale Mengen an Hopfen rein zu hauen.

P.P.S: ja, ich weiß, es gibt leckere IPAs, trotzdem!

Da sprudeln die Aromen! Viel Malz und die typisch belgische Brettanomyceshefe (nehme ich an, wer weiß?). Dazu eine leichte Süße und schon ist man froh, dass nur 0,3l in der...

Hm, „feinherb“. Von mir aus könnte es ruhig etwas „grobherber“ sein. Deutlich grobherber.

Hm, „feinherb“. Von mir aus könnte es ruhig etwas „grobherber“ sein. Deutlich grobherber.

So Apple has a new programming language called Swift. You probably heard the news and read the Swift book so I wont bother repeating the good parts. I fell in love with nearly all of the new features (compared to C/Objective C) only from reading the Swift book BUT…

There are some foul spots in that sweet fruit. I gave this post the title „two WTFs, a Fail and a Train Wreck“ to sum up my gripes. Let’s start with the first WTF:

First WTF – Constant Arrays

In the Swift book it says:

if you assign an array or a dictionary to a constant, that array or dictionary is immutable

Ok, so far so good. Exactly what you would expect.

„…and its size cannot be changed.“

Wh..what’s that? I’m confused! Let’s read on.

For dictionaries, immutability also means that you cannot replace the value for an existing key in the dictionary. An immutable dictionary’s contents cannot be changed once they are set.

Ok, still as expected.

Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array.

WHAAAT??? Ok, nice optimization but aren’t that weird rules? I use a constant because I want it to be constant and not to have a faster variable. The implementation details should not shine through like that!

If you really want to have fun, try to wrap your head around the chapter „Assignment and Copy Behavior for Arrays“ in the Swift book. That mad endeavour is left as an exercise to the reader. Good luck!

The Fail – Method names

One of the greatly undervalued gems in Objective C is that there is no difference between the name of a method and the named parameters. It’s the same thing, and it can be rather poetic:

[url bookmarkDataWithOptions:NSURLBookmarkCreationMinimalBookmark
includingResourceValuesForKeys:nil relativeToURL:nil error:nil];

becomes this abomination:

url.bookmarkDataWithOptions(options: NSURLBookmarkCreationMinimalBookmark, includingResourceValuesForKeys: nil, relativeToURL: nil, error: nil)

urgh! „Options“ twice. Not good! There is no reason Swift could not have retained the elegant square bracket syntax of Objective C. None. Still they force us to cut the first part of our method name in half with a round bracket. Thank you so much.

Second WTF – Closure Syntax in a Method/Function Invocation

According to the Swift book you can call a function with a closure as a parameter like this:

reversed = sort(names, { (s1: String, s2: String) -> Bool in return s1 > s2 } )

or like this:

reversed = sort(names, { s1, s2 in return s1 > s2 } )

or like this:

reversed = sort(names, { s1, s2 in s1 > s2 } )

or like this:

reversed = sort(names, { $0 > $1 } )

or (in this case) like this:

reversed = sort(names, >)

or like this:

reversed = sort(names) { $0 > $1 }

Any questions?

The Trainwreck – Operator overloading

Whew that’s a big one! Obviously Chris Lattner and his team have not read Scott Meyers „Effective C++“ and „More Effective C++“ back then in the mid-nineties. Meyers makes some good cases against using operator overloading in C++, which is an especially hellish place anyway. But some cases are relevant beyond C++. Let me pick one, the boolean operator problem. Let’s assume we have two functions a() and b() that return a BOOL (or Bool). When we use a if-clause like this (in C)

if (a() && b())
{ /* do stuff */}

and a() returns false, b() will not be called. You can question this design decision by Kernighan and Ritchie from over 40 years ago but this behaviour has made it into many, many languages since then and Swift is no exception. Open a playground and copy and paste as we move along for maximum fun:

func a () -> Bool {
return false
}

func b () -> Bool {
println("b() was called")
return true
}

if a() && b() {
println("YES");
}
else
{
println("NO");
}

The console contains no surprise:

NO

Now let’s do some mean operator overloading with 3 components:

// a class
class Blah {
}

// an overloaded &&-operator
@infix func && (left: Blah, right: Bool) -> Bool {
return a() && right
}

// finally a func that returns a Blah object
func c () -> Blah {
return Blah()
}

Now let’s do the same if-clause but with c() instead of a():

if c() && b() {
println("YES");
}
else
{
println("NO");
}

Guess what happens?

b() was called
NO

Ouch! This behaviour is totally expected but just as surprising at the same time. It is not easy to tell what really happens from looking at the code
if c() && b()
That’s bad. It basically means you can’t trust the evaluation rules for operators anymore. That’s a train wreck! Especially for a language that tries so hard to avoid those kinds of problems.

Probably as you read this some kid out there thinks it’s a good idea to create and use a %%%-operator in his library. He might just have pushed it to Github. Who knows? Or imagine someone thinks how cool it was to port std::stream of the C++-STL to Swift, does so and your boss likes it? Nothing wrong with the STL back then when your boss still wrote code, right? RIGHT?

But joking aside: There are so few problems you can only solve with operator overloading but so many problem to have with it. It really makes you wonder: How could this get past the reasonable people in the team of Chris?

I’m at a loss here. I have no idea.

So Apple has a new programming language called Swift. You probably heard the news and read the Swift book so I wont bother repeating the good parts. I fell in...