Microsoft announced Visual Studio 2017. Yeah, Party.

I am so hyped, because with it comes C#7.0. I am speaking of tuples, pattern matching and local functions. This will be great. Soon ☺️🎉

This one fucking comma just cost me 20 mins of debugging 😤

Java:
Primitive streams. Their need to exist is a monument to legacy failure.

VB.net
OrElse and AndAlso short-circuiting operators. The language designers were too fucking lazy to process logic, so they give specific keywords for those cases.

PHP
Random Hebrew error messages

JS
Eval. It can be used responsibly, but most of the times you see it it's because someone fucked up.

C#
Lack of Tuple destructuring in argument specification. Tuples were added, and pattern matching was added, and it's been getting better. The gear grinding starts with how Tuple identity assignment in arguments is handled. Rather than destructuring into the current scope, it coalesces the identity specification into a dot property of whatever the argument name is. This seems like an afterthought given they have ootb support for ignore characters.

Typescript
This will probably be remedied in the next version or two, but Tuple identity forwarding between anonymous scopes normalizes to arrays of union types, because tuples compile to typeless arrays. It's irritating because you end up having to restate the type metadata in functional series even when there is no possibility for any other code branch to have occurred.

Why is it so important to some people to claim that "HTML and CSS are not programming languages"? I get it, you're a REAL programmer working with arrays, maybe tuples, objects and possibly direct memory management. Who the fuck has a right to call themselves a programmer for writing some brain dead markup or poorly designed selectors, right? Who fucking cares for semantic tags or nested selectors?

Just think for a few seconds about when you were taking your first baby steps to becoming the GOD ROCKING MEMORY HANDLER THAT WRITES _REAL_ CODE that you are today, and how good it felt to be able to create something that appeared on your screen. It felt pretty awesome, yeah?

Now imagine if someone much more experienced than you told you "You're not a real programmer, that is not real programming. You should see what I do, I do real programming".

I think you get it. Why spend your energy spreading bad vibes when you could spend it on something more productive. Like reading up on the new CSS4 specs ;)

C# FTW! New features for C#7.0:
blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/
tuples, pattern matching, local functions *coder-gasm*

So I was writing docs for my project the hard way. Manually. Every time I added something new, I had to find the right place for it to be alphabetically in the reference. And god forbid I want to have the same information in two pages: I would need to copy/ paste and pray that I not forget to update the information EVERYWHERE.

I didn't feel like installing and learning some new markdown generating bullshit so I just made my own system. It's very simple and intuitive and I love it.

I made sure it can cover two use case: reading partial documents from the disk, and rendering in-memory objects to markdown too (like rendering a collection of tuples into a table)

I didn't care much for templating, so there's no templating capability.

I just learned Javascript doesn't have tuples and nearly cried and/or vomited all over my keyboard. Pls no.

Why are authors of highly performant code allergic to readability?

I spent a whole day trying to debug why the backend would stop sending data after a while (-> it filled up its connection pool)
but after I turned pooling off, there were a number of dangling Client-Idle-Read DB connections
//not using Entity Framework in these N services, it's pure SQL and DB-AccessLayer here

Never happened before, looked up conf, looked up SO
Changed connectionClose to mandatory Dispose
Still didnt work.

long story short. Turns out in 1 of the services, the DataReader to POCO static method, was disposing/closing the READER and not the CONNECTION.

I sent it as tuple instead of 2 separate variables (reader, connection), and the Item1, Item2 got mixed up (:

Totally my fault, and imma avoid name-less tuples from now on like they a plague -.- thats my 2024-resolution

This error, which took me a long time to find, demonstrates the importance of useful variable names.

Using the Wolfram Language:

pp = {};
For[i = 0, i <= Max[p], i++, If[Count[p, i] != 0, pp = Join[pp, {{i, Count[pp, i]}}], -1]];
pp

Outputs:

{{1, 0}, {2, 0}, {3, 0}, {4, 0}, {5, 0}, {6, 0}, {7, 0}, {8, 0}, {9, 0}, {10, 0}, {11, 0}, {12, 0}, {13, 0}, {14, 0}, {15, 0}, {16, 0}, {17, 0}, {18, 0}, {19, 0}, {20, 0}, {21, 0}, {22, 0}, {23, 0}, {24, 0}, {25, 0}, {26, 0}, {27, 0}, {28, 0}, {29, 0}, {30, 0}, {31, 0}, {32, 0}, {33, 0}, {34, 0}, {35, 0}, {36, 0}, {37, 0}, {38, 0}, {39, 0}, {40, 0}, {41, 0}, {42, 0}, {43, 0}, {44, 0}, {45, 0}, {46, 0}, {47, 0}, {48, 0}, {49, 0}, {50, 0}, {51, 0}, {52, 0}, {53, 0}, {54, 0}, {55, 0}, {56, 0}, {57, 0}, {58, 0}, {59, 0}, {60, 0}, {61, 0}, {62, 0}, {63, 0}, {64, 0}, {65, 0}, {66, 0}, {67, 0}, {68, 0}, {69, 0}, {70, 0}, {71, 0}, {72, 0}, {73, 0}, {74, 0}, {75, 0}, {76, 0}, {77, 0}, {78, 0}, {79, 0}, {80, 0}, {81, 0}, {82, 0}, {83, 0}, {84, 0}, {85, 0}, {86, 0}, {87, 0}, {88, 0}, {89, 0}, {90, 0}, {91, 0}, {92, 0}, {93, 0}, {94, 0}, {95, 0}, {96, 0}, {97, 0}, {98, 0}, {99, 0}, {100, 0}, {101, 0}, {103, 0}, {104, 0}, {105, 0}, {106, 0}, {107, 0}, {108, 0}, {111, 0}, {112, 0}, {116, 0}, {118, 0}, {122, 0}, {125, 0}, {136, 0}, {137, 0}}

As opposed to the expected output, which should have no 0s as the second values in any of the tuples.

I spent a large amount of time examining the code to generate p before realizing that the bug was in this line.

I've been working with Node and Typescript for a while now, and I wrote a wide array of very general utility functions. Examples include:
- Array.filter but you also get the residue array, it can also leave holes in both arrays if you want to join them later
- Array zipping and unzipping to and from tuples (especially valuable when you're manipulating the prop set with Object.entries() in a HOC
- Array maximum selection, with an optional mapper
- Cancelable promises, lazy promises, a promise that resolves when a given function on an object is called (excellent for DOM events), a timeout promise.
- A typed event with both immediate and microtask listeners depending on whether you need state guarantees (this idea I took from a Github gist and upgraded it)

I want to put them on NPM so I don't have to write them and their tests again, and so that if I ever think of an improvement it's easier to propagate it. Do you think I should release them as tiny individual packages which would be nice from a versioning standpoint, or should I make them into a compilation which would be a lot less work for me (and therefore would probably result in better documentation and more tests)?

3 hours in to work and I've already wished Java had two more features: native tuples and partial application in method references.

*looks drowsy* Ugh my head..

You know what, guys? If you can freshly and directly remember how to do this:

- calculate the time complexity for each type of loop and code structure

- knowing how to write the following regex:
"A 15-digit number starting with a possibility of a group of 1-2 digit numbers, segregated into three 5-digit numbers tuples with three different separator characters, evaluated ahead"

- mentally work out how to reverse an array's indexes (swapping algorithm) without writing anything down

- know how to optimize a binary search in your head

then kudos to you. lmao
I'm rusty. It took me a while..

My two main grudges against Typescript:
1) Union types can't be passed as arguments if there is a variant for every element of the union
2) No tuple polymorphism, i.e. [T, U] isn't assignable to [T]. This is not a mistake because the length of the arrays differs and therefore they may be interpreted in a different way, but IMO there should be a tuple type which is actually an array but length is unavailable and it supports polymorphism. This sounds stupid, but since function parameter lists work well with tuples it would actually enable a lot of functional tricks that are currently inaccessible.

I've never had any use for Pythons tuple unpacking until today when building objects from SQL selects. I always thought it was kind of a lame feature, now I think it's awesome.

Orchid lesson #many:
Church tuples exist only to demonstrate how general substitution is. Just like Church numerals, they aren't meant to be used for real computation and cause a lot of problems. Few type systems and fewer optimizers can deal with them, they're a pain to pass through FFI boundaries, and they're much slower in an interpreted context than a native smart array. And in a lazy language the tuple is almost always lighter than the code that generates it, so you want to generate the tuple eagerly and thunk the actual elements, if thunk you must.

I'll go write a vector based tuple and end this madness tomorrow. New version soon, probably.

With dynamic dispatch.

So, I feel wayyy behind the tech curve right now.

The SSD implementations you see online, they're still just a bunch of seperate sort of chaos machines that contain the standard perceptron-like model of a weight, cost, and bias right ? They just kind of inferred their values by training like any other neural network, in its sep-erate parts and just fed pieces of output data generated by other parts of the neural network to it right ?

I mean it implements with pytorch so its basically a really big array of tuples in a sense that are maniupulated in a specific way.

and then CNN's just feed data back into another trained piece of the model right ?

I'm curious because object classification is about the ONLY thing I've seen work even close to properly lol

there is just so much fraud these days. sigh.
and so many lamentable tech choices and attempts... like node lol

In type systems without variadic generics, tuples should be defined as a type-level conslist:

Tuple<int, Tuple<string, Tuple<bool, TupleEnd>>>

Consider the possibilities, even just in a regular type system, then consider how much more is possible with dependent types!