I found this on a wiki with Haskell Humor... it's interesting...

How to Shoot Your Self in the Foot With Haskell: Putting the unsafe in unsafePerformIO!

You shoot the gun, but the bullet gets trapped in the IO monad.
Couldn't match expected type 'Deer' against inferred type 'Foot'.
While compiling your program the compiler produces a type error long enough to overflow a kernel buffer, overwrite the trigger control register and shoot you in the foot.
After trying to decipher the type errors from the compiler, your head explodes.
After you've finally found a way to circumvent the type system and shoot yourself in the foot, Oleg appears out of nothing and shoots you in the foot for coming up with it before him.
You shoot the gun but nothing happens (Haskell is pure, after all).
Your foot is fine, until you try to walk on it, at which point it becomes mangled.
You have a shootFoot function which you've proven correct. QuickCheck validates it for arbitrary you-like values. It will be evaluated only when you end up at the hospital. You hope this doesn't come to pass, as it actually returns a bullet-ridden copy of yourself and you don't want to be garbage-collected.
foreign import ccall "shootparts.h shootfoot" shoot_foot :: Gun -> Programmer -> IO ()
shootSelfInFoot = unsafePerformIO . shoot . foot $ self -- Shoot self in foot 0 or more times depending on evaluation order
No instance for (Target Foot)
arising from use of `shoot' at SelfInflictedInjury.hs:1:0
Possible fix: add an instance declaration for (Target Foot)
In the expression: shoot foot
You go to shoot yourself in the foot but the bullet is in the ST monad and the gun is in the IO monad, so you can't.
You ask Haskell to shoot you in the foot but by the rules of lazy evaluation you don't need the result yet so it doesn't happen.
You decide to shoot yourself in the foot but get distracted devising a ballistics algebra and wondering if you can do the calculations in the type system.
You want to shoot yourself in the foot but realize there is no Gun datatype so use Arrows instead.
You shoot in the direction of your foot, but since you are inside the STM monad you can just retry until you figure out what to do.
You shoot yourself in the foot, but you are perfectly fine as long you just don't evaluate the foot.
You shoot yourself in the foot, but nothing happens unless you start walking.
Don't forget about memory consumption! If you don't look, the bullet causes heap overflow. If you look, the bullet causes stack overflow.
You *appear* to have deliberately shot yourself in the foot, and yet your program actually runs perfectly OK due to lazy evaluation. (So long as you remember to not look at your foot...)
You aim the gun at your foot, pull the trigger and remove the clip. When you look at your undamaged foot, the hammer clicks on an empty barrel.

We had a school project where we where supposed to implement a software with a heavy client in C# and web services for it in C#, but the web services HAD TO COMMUNICATE WITH SMTP AND IMAP. And do that in 8 days.

We were 6 in the team. 4 had no idea what a web service is, and I and the designated project lead were the only ones knowing what to do. The lead had paperwork to do for the project, so I had to do everything but the UI alone. So 1 guy did the UI, 3 were... Playing Minecraft... The lead was doing paperwork and ranting about how noisy idiots these guys were... And I was sick as hell and could not eat anything, I was vomiting all day in between which moment I managed to make half of the functionalities of the project, despite having to go to the hospital and have to continue working despite the medical request not to work.

So the day before the presentation I had half of the functionalities done and I had to explain them yet another time what web services are so they can answer the questions and cover for themselves.

On the day of the presentation it went kinda fine. It was not finished but it worked like asked.

We were asked for peer evaluation and I gave A to the lead and the UI guy and B to the 3 other lazy asses.

Shortly after I am called by the tutor in the office : "What happened on this project? Were you not working at all? Apart for the lead who gave you an A, every one gave you a D (lowest grade). I demand for explanations"

I said never mind and got back to studying. I got a B, all the rest of the group an A.

Why is it that virtually all new languages in the last 25 years or so have a C-like syntax?

- Java wanted to sort-of knock off C++.
- C# wanted to be Java but on Microsoft's proprietary stack instead of SUN's (now Oracle's).
- Several other languages such as Vala, Scala, Swift, etc. do only careful evolution, seemingly so as to not alienate the devs used to previous C-like languages.
- Not to speak of everyone's favourite enemy, JavaScript…
- Then there is ReasonML which is basically an alternate, more C-like, syntax for OCaml, and is then compiled to JavaScript.

Now we're slowly arriving at the meat of this rant: back when I started university, the first semester programming lecture used Scheme, and provided a fine introduction to (functional) programming. Scheme, like other variants of Lisp, is a fine language, very flexible, code is data, data is code, but you get somewhat lost in a sea of parentheses, probably worse than the C-like languages' salad of curly braces. But it was a refreshing change from the likes of C, C++, and Java in terms of approach.

But the real enlightenment came when I read through Okasaki's paper on purely functional data structures. The author uses Standard ML in the paper, and after the initial shock (because it's different than most everything else I had seen), and getting used to the notation, I loved the crisp clarity it brings with almost no ceremony at all!

After looking around a bit, I found that nobody seems to use SML anymore, but there are viable alternatives, depending on your taste:

- Pragmatic programmers can use OCaml, which has immutability by default, and tries to guide the programmer to a functional programming mindset, but can accommodate imperative constructs easily when necessary.
- F# was born as OCaml on .NET but has now evolved into its own great thing with many upsides and very few downsides; I recommend every C# developer should give it a try.
- Somewhat more extreme is Haskell, with its ideology of pure functions and lazy evaluation that makes introducing side effects, I/O, and other imperative constructs rather a pain in the arse, and not quite my piece of cake, but learning it can still help you be a better programmer in whatever language you use on a day-to-day basis.

Anyway, the point is that after working with several of these languages developed out of the original Meta Language, it baffles me how anyone can be happy being a curly-braces-language developer without craving something more succinct and to-the-point. Especially when it comes to JavaScript: all the above mentioned ML-like languages can be compiled to JavaScript, so developing directly in JavaScript should hardly be a necessity.

Obviously these curly-braces languages will still be needed for a long time coming, legacy systems and all—just look at COBOL—, but my point stands.

I just love code-golf, I only started recently, but sometimes it's nice to fuck all coding conventions, missuse lazy evaluation and abuse scope leaking.
I'm normally really tidy with formating and whitespace placement, but code-golf is also a testing field for uncommen constructs and I think it can give deeper insights into a language.

I don't like languages specifically for code-golf though, these are just stupid and no fun (at least for me).

Junior dev here

Implementing client side search functionality using Highland.js with its streams and lazy evaluation.

Hopefully I haven't bitten off more than one can chew. Higher order streams have been known to confuse me.

On a related note, Googling "forked streams" yields interesting results.

I built a view engine that relied on V8 for expression evaluation and flow. Not very stable of course, since it used RegEx, but it worked fine for what it was designed for.
The crown feature was the ability to pass in lazy-evaluated huge objects to that view model, so that the view model decided what was going to be used in order to display the view. Made it really flexible, while not sacrificing speed.

I was brainstorming for 2 days about the lazy loading part, and the gymnastics that had to be implemented for this to work.

After I wrote my final line of code and thought that this is it, I launched it, and it FUCKING WORKED! First try!
I was hyperventilating, walking around the apartment like crazy, doing random push-ups just to try to utilize some energy that I felt was fighting to burst out like a xenomorph out of the chest.

... 2 weeks later I found bugs. Had to re-learn how I did it. It's true what they say: if it was hard to write, it's even harder to debug. Fixed it eventually, but that part's not that exciting.

Other build tools:

Here is a plugin, use it . Be done.

Scala Build Tool aka SBT:

Build your own plugin.

Everything is scala...
You can create by the way funny endless loops when using the wrong syntax - yet it might compile successfully. And then when you load the plugin, it works. Till it is evaluated - lazy evaluation for the fun.

Error messages are at best cryptic.

*If* you manage to get a working plugin and *if* it runs...

Surprise. Surprise.

You might need to parse the log output of SBT.

Another funny surprise: Log output isn't configurable. You can configure the log level. That's it.

So after a lot of pain stakingly putting together a fucking shitty plugin, you can now grind the rest of your brain with ...
sed.

Cause yeah. You can now use regex to parse an sbt build log and extract the necessary information.

:)

...

So....

Are we there?

Mwahahahhaa.

Only if you haven't forgotten to either disable colored output for SBT... Or take an extra mile with e.g. less -R.

Otherwise you have ASCII control characters in your file. :-)

After getting that shit to work, you now have finally a parseable build log.

Just took days instead of hours.

But that's SBT. :-)

do you ever separate the structure of a collection from the values held within to allow queries about the structure to be deferred arbitrarily without keeping the values alive through that reference, or is my project just terminally fucked?