Live data from Hacker News

The Functional Programming Hiring Problem

blog.janissary.xyz

111–120 of 140 posts

Re: The Functional Programming Hiring Problem

#111
post #65
post #42

Earlier quoted context omitted.

What is bad about encoding/json?

There is a version 2 being implemented to fix some of the known issues. https://github.com/golang/go/discussions/63397 https://pkg.go.dev/github.com/go-json-experiment/json

Thanks for the link. It looks like it might be a bit less painful?

It's still a pretty sharp disappointment to compare Go's json/encoding to Python's Pydantic or Rust's serde. One is all sharp edges, bad DX that permeates every use you make of them, and its only upside is that it provided as part of the stdlib. The other two are unobtrusive and just work.

Re: The Functional Programming Hiring Problem

#112

Earlier quoted context omitted.

> What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both benefits and problems. > The benefit is they will generally be capable of greater innovation than the former group, but the downside is t…

> who love to think about whether there is a deeper hidden mathematical structure behind the business problems. Yup and lots of whom started with programming as a hobby, and could chase after any shiny thing they saw, or run off whenever on any side quest that interested them. Nobody wants to pay you hundreds of thousands of dollars to navel gaze, or run off down whatever path you feel is mathematically satisfying. D…

> You're being paid hundreds of thousands dollars to deliver business value - so do that. Build mathematical towers on your own time.

A better understanding of the deep underlying structure behind the business problems is a step towards proving business value. This is exactly what I mean with a " much less anti-intellectual way of approaching [business problems]".

Re: The Functional Programming Hiring Problem

#113
An insightful post, this point resonated with me in particular…

However, I think that we all need to be a little more honest with ourselves as software engineers. […] Are you sure you don't use Gooby just because it's fun to write?

Why? I use raku every day just because it’s fun to write!

Re: The Functional Programming Hiring Problem

#114
post #3

> The multi-armed bandit is a really interesting problem in mathematical optimization... This problem is so interesting, in fact, that during World War II the Allies proposed air dropping copies of the original paper over Germany. The end result, or so it was theorized, was that German scientists would be so fascinated and distracted by the problem that they would abandon the war effort and cripple any German militar…

I would say "citation needed". Who said it? Where?

Re: The Functional Programming Hiring Problem

#115

Earlier quoted context omitted.

Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.

I may indeed be outdated. Does Microsoft now support deserializing into dynamic for example?

You should never do that. Please do not, and I can't stress this enough, use `dynamic`.

If you need DOM-style JSON handling, please use JsonDocument and JsonNode instead: https://learn.microsoft.com/en-us/dotnet/standard/serializat...

Re: The Functional Programming Hiring Problem

#116
post #37

Earlier quoted context omitted.

At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently. Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done. I do get cau…

> At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. This is the right attitude

It’s just not that hard. Problem domains are hard. If you asked me to work in computer vision that’d be hard for me. Same for high frequency trading. Asking me to write this device driver in rust versus nasty old C, whatever man, bits is bits. I lie about my experience in different stacks solving the same old troubles all the time.

Languages are boring. Problem domains can be a lot of fun.

Re: The Functional Programming Hiring Problem

#117

Earlier quoted context omitted.

> What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both benefits and problems. > The benefit is they will generally be capable of greater innovation than the former group, but the downside is t…

> who love to think about whether there is a deeper hidden mathematical structure behind the business problems. Yup and lots of whom started with programming as a hobby, and could chase after any shiny thing they saw, or run off whenever on any side quest that interested them. Nobody wants to pay you hundreds of thousands of dollars to navel gaze, or run off down whatever path you feel is mathematically satisfying. D…

> "Don't you see the deeper hidden artistic structure!?"

This comes across as very snarky. The word used was "mathematical", not "artistic". Mathematics has proved invaluable in many domains of business.

Re: The Functional Programming Hiring Problem

#118

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

I don't see why anyone should be a $LANG dev. All programming languages suck (there is this theoretical language that doesn't suck, but it isn't invented yet). Surely $LANG devs recognize that their language sucks, right? And that's why we switch languages constantly. For some problems, some languages suck a little less.

Gooby doesn't suck though. (I'm not joking.)

Re: The Functional Programming Hiring Problem

#119

Earlier quoted context omitted.

I may indeed be outdated. Does Microsoft now support deserializing into dynamic for example?

You should never do that. Please do not, and I can't stress this enough, use `dynamic`. If you need DOM-style JSON handling, please use JsonDocument and JsonNode instead: https://learn.microsoft.com/en-us/dotnet/standard/serializat...

There are plenty of cases where dynamic saves a ton of code.

Re: The Functional Programming Hiring Problem

#120

Earlier quoted context omitted.

> who love to think about whether there is a deeper hidden mathematical structure behind the business problems. Yup and lots of whom started with programming as a hobby, and could chase after any shiny thing they saw, or run off whenever on any side quest that interested them. Nobody wants to pay you hundreds of thousands of dollars to navel gaze, or run off down whatever path you feel is mathematically satisfying. D…

> You're being paid hundreds of thousands dollars to deliver business value - so do that. Build mathematical towers on your own time. A better understanding of the deep underlying structure behind the business problems is a step towards proving business value. This is exactly what I mean with a " much less anti-intellectual way of approaching [business problems]".

A better understanding of the deep underlying structure behind the business problems can be a step towards proving business value. Or it can be interesting to a small number of people, but completely useless.

Of course, the people to whom it is interesting think that the case they're interested in is almost certainly in the "providing business value" category. In their enthusiasm, they probably over-estimate the odds...

Post reply on HN