Nvorzula

I'll throw in my own niche usecase for thermoelectric - deep sky imaging.

I do astrophotography as a hobby (taking pictures of galaxies/nebulae/etc). This involves doing long, multi-minute, exposures repeatedly all night long. The heat generated from such long exposures produces what are called "hot pixels" - noise generated by heat disrupting the electronics.

To combat this, dedicated deep sky imaging cameras run a thermoelectric cooler to bring the sensor to sub-zero temperatures. These sensors tend to be about 23.5×15.7mm in size.

Niche, sure. But I saw an opportunity to bring up an aspect of my own life where I sincerely do not think even the smallest compressors would be practical. Plus, the lack of moving parts in thermoelectric is very attractive.

Hello, astrophotographer here.

The unique thing about astrophotography is that the subject that we are imaging is (relatively speaking) static. Any slight deviation, even the smallest detail, that is not structurally accurate is PAINFULLY obvious.

As an aside, we do use traditional neural networks for certain processing steps. Deconvolution and noise reduction are very common. However, these are only helping in correcting errors caused by viewing conditions. They are not the "imaginative" AI that you are dreading.

How is it odd and entitled for an end user to not like it when things suddenly break?

That is, I believe, the entire point of the parent, is it not? That this whole migration was not quarantined to the Python developer community. That it spilled over to users in totally unrelated spaces.

> Russia in rubble in two weeks from sanctions and Russia out of missiles in two weeks.

I'm not sure I ever heard such promises. In fact, I distinctly remember the opposite being the general zeitgeist of the time - that Russia would rollover Ukraine with little resistance.

Of all the things to backup, how does a technician NOT include Documents/Pictures?

"Oh, I know, better save these DLLs. Also, a copy of the registry juuuuust in case they changed some obscure IE8 settings and want that on their new system."

> "where might I use this function?"

I'm not so sure about this one. Software development is quite usually "build functionality to serve a given use case" whereas this line of inquiry is more along the lines of "find a use case for the given functionality".

Perhaps if you intend for the conversation to head into a chat about charting and data science?

Some time ago I got into the habit of naming my home network after Pokemon that I happen to thought fit well. My Windows desktop is Charizard and it's Ubuntu dual boot is DarkCharizard. My fileserver/Docker box is Metagross. My wireless SSID is Raichu, my laptop is Pikachu, and my phone is Pichu. And so on.

Precisely, this is Rust that compiles to a C FFI that plugs into CPython.

To my understanding they're both [type, length, content] encoded formats, so they're similar there at least.

In my experience people really quite enjoy the IDL aspect of protobuf as the killer feature, and I am not sure any such compiler exists for ASN1.

This is the precise insight that jumped out at me.

I often get raised eyebrows when I state that, by my definition, Python and Javascript are among the mostly brutally difficult programming languages out there.

Python is a wonderful candidate for one-off tooling and experimentation, particularly because the cost of wild explosions in these cases, and the odds of requiring long term maintenance, are rather low. However, if your plan is to hire fresh college grads, hand them a Python 2.7 interpreter, and ask them to a build a mission critical, 200k+ line, product - that just seems professionally negligent.

Of course there is academic interesting (as in, I wrote an emulator in BASH and it actually kinda works) and there is practical interesting (I got the emulator to be 3% faster).

The Rust community really has an interest in showing the world that it is a serious candidate to replace C++. That's why we see a preponderance of "this same problem, but solved in Rust" - they're providing another data point to show that Rust can work in a problem space that had previously been the sole domain of C/C++. In that regard, I would think it interesting.

> The most offensive thing people are doing with design patterns is trying to use them like bricks to build code. You will end up with code that’s 90% boilerplate and 10% actual logic strewn all over the place.

This is absolutely one of my greatest pet peeves with the developers I have been interacting with the past several years. It is almost as though they ignore all functional and non-function requirements set forth before them, instead placing a priority on having no fewer than four `AbstractSingletonFactoryAdapor`s. The result is the complete abuse, and misuse, of these patterns that is just impossible to follow and almost always incorrect (Really? A singleton? Do you REALLY think that there will only ever be one logged in user during the life of the JVM? Or did that just HAPPEN to be the case while you were sitting at your desk pounding this out?).

With regard to datacenter operators, I would argue that a simpler answer to that observation is that they are investing heavily in the are in which they can actually effect change. That is, they can swap in-and-out their hardware, but language of choice is largely up to their customers - the dev. They can advocate and champion a particular language, but really enforcing it in any meaningful way is narrow casting their own user base.

Here's one that always has me stare at the screen, quietly, in disbelief.

1. Carefully read and grok a small-to-medium sized module. 2. Notice that although the style is not the "official" style of that language, that it is very consistent and legible. 3. Contribute a small change in that exact same style, such that no one would know that it was a different author if they did not look at the git blame. 4. Get a condescending comment from the first author asking that you, "read and follow the official BLANK style guide".

I actually live in the greater Phoenix area and go to school at ASU, so I see Waymo and Uber autonomous around everywhere. I frequently see these things handle aggressive rush hour traffic with university pedestrians jumping out into the middle of traffic. They stay safe, but they clearly have a sense of when to go for it.

On the whole I am very happy with Go, but this did bite me recently. We're using the X509 package which is returning an error on a handful of CA certificates due to characters that are not technically allowed in an ASN.1 PrintableString field (E.G `&`). Sure, fine, we've already forked the package so it's easy to make the change to be more lenient. Except errors don't contain any information about the origin of the error in source code, so it's been down to painful debugging and source code digging to find where this check is being made.

If anyone has a less painful way to do this, please halp.

x := some_code_here says "x is a NEW variable whose type is whatever the result of the expression on the right hand side is".

Say we have a function, GetInt64(), which...returns an int64. x := GetInt64() both declares x to be an int64 and places the resulting value of the right hand side into x. If x was already to declared to be an int64, E.G.:

var x int64

x := GetInt64()

Then the compiler complain that x is not new - it has already been declared. In this case you have to omit the colon to remove the fancy "auto" semantics.

var x int64

x = GetInt64()

> I argue that clear use of function pointers is the heart of object-oriented programming. Given a set of operations you want to perform on data, and a set of data types you want to respond to those operations, the easiest way to put the program together is with a group of function pointers for each type. This, in a nutshell, defines class and method. The O-O languages give you more of course - prettier syntax, derived types and so on - but conceptually they provide little extra.

I think that this might be an early hint at Go's interface system and its lack of of "complete" OOP support.

A lot of people are commenting on how cheapskate I was. Absolutely! I was still in undergraduate and this was my first contracting gig. I am older, wiser, and ahem richer now. =)

I took a dive away from Sublime Text over to Atom a few years ago because I was starting up some contract work, didn't want to pay for a copy, and didn't want to continue doing the hokey thing of using a friend's license for work purposes. So I got use to Atom just fine, plus the UI is nice.

I mean, Atom is nice. The package management is all there and frequent updates are great, but...I don't write JS/HTML/CSS/PHP. I typically write Python, Go, Java, and heck even Prolog. Reading the changelog you can clearly see that they have a target audience, and I am not in it.

On the performance side (you knew it was coming!) I am mostly fine except for opening a project directory. I swear Atom has a coded in `sleep` whenever you try to open a file explorer. At first, I thought that this was a cute little quirk that would disappear after an update one day. But that update never came.

So I'll download Sublime again. Spend a morning to get it "just so" for, at the very least, Python and Go. I can easily see Sublime winning me back if I reinvest in it.

He points to a graduate student who had to pick up Python for some task and wanted to learn both the language and the tools necessary for that task. I can throw another anecdote into the ring and mention a web data mining course I'm taking right now where a lot of students are having to pick up Python along side both scikit-learn and scrapy.