Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Functional Programming Hiring Problem

blog.janissary.xyz

Post reply on HN
Print view View original

71–80 of 140 posts

Re: The Functional Programming Hiring Problem

#71

Post by BeetleB »

jballanc wrote: post #68
kccqzy wrote: post #4

This is just a hiring problem, not related to functional programming. I agree with the basic premise of the article however: depending on the financial condition of the company, hiring people who are overly attached to or obsessed with a single technology probably isn't a good idea. But that's of course not exclusive to functional programming. Right now you will find plenty of people obsessed with Rust (not a functio…

This is why one of my favorite series of questions to pull out during an interview are: What is your favorite programming language/library/technology? What do you hate about it? Anyone that jumps to answer the first but struggles to answer the second is likely not someone you want to hire.

Ok. For anyone struggling with the second, the answers should be:

Lack of libraries.

Lack of good tools.

Re: The Functional Programming Hiring Problem

#72

Post by Hasnep »

eric-hu wrote: post #47
jsyang00 wrote: post #23

The author brings up some good points here, but I would just make sure to build my business around trading obscure financial instruments in a clever way, so as to generate such an overwhelming amount of profit that we can singlehandedly rewrite and maintain everything in our stack from scratch. I acknowledge, however, a lot of people never think to do this when starting their business, and consequently run into all s…

Is this a reference to one particular company/language?

Sounds a bit like Jane Street with OCaml

Re: The Functional Programming Hiring Problem

#73

Post by saithound »

tjbai wrote: 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…

It's so incredible you should not believe it.

Multi-armed bandits were introduced in the 50s, years after the end of World War 2.

Re: The Functional Programming Hiring Problem

#74

Post by throwawaymaths »

I'm actually suffering from the opposite problem. CTO is a well known Gooby developer. But we wrote everything in C++ because "it will be easier to hire down the line", pulling in well known C++ libraries by various bigcos that actually don't compose together and make a royal mess of the codebase. We've missed every single deadline, and are light years behind where we should be.

Honestly we should have written it in C, but I'm too far down the totem pole to make that call

Re: The Functional Programming Hiring Problem

#75

Post by jqcoffey »

lll-o-lll wrote: post #52

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. 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 ben…

I can't plus this enough. I hired a unicorn business minded, brilliant, can solve any software engineering or UI/UX problem engineer who happened to have a predilection for functional programming.

I found out that unicorns are unicorns.

Re: The Functional Programming Hiring Problem

#76

Post by nequo »

skydhash wrote: post #60
jll29 wrote: post #16

In 2005, I needed to hire a Haskell dev with deep NLP expertise to replace a member of my startup team. After a posting on the Haskell mailing list, zero responses came back. We realized the world had about 3 people that matched all the requirements: one was the dev that needed to be replaced, the other one was a tenured professor of a U.S. university (Hi, Hal!), and there was one more, whom I don't remember but it m…

> and my conjecture is there might be something about keywords that makes them superior cognitively for humans compared to just piles of nested parentheses. It's the nature of the language and the VM that it runs in. The code is data and data is code. You can construct a list and then decide to evaluate it. Or the current code you're writing is actually data for another piece of code. It's a paradigm that really open…

> You can inspect anything, patch anything. When paired with an editor, that means you can only apply part of the code and then rerun part of the code. You can also try stuff and then formalize stuff down in code, no need to rerun the whole program.

I’ve heard this a lot about Lisp. But doesn't this lead to greater cognitive complexity because every time you patch your running code, you have to keep in mind the state of the running program and mentally check whether your patch affects any part of that state?

A lot of people do data analysis this way in R/Python who aren’t programmers either by training or for a living, and it is not a practice that generally leads to bug-free outcomes. This has also mirrored my experience with Emacs which is a Lisp machine, maybe getting closer to Common Lisp’s programming environment.

Is this process of runtime modification fundamentally different in CL? What am I misunderstanding?

Re: The Functional Programming Hiring Problem

#78

Post by BWStearns »

pram wrote: post #66
BWStearns wrote: post #13

I work at a place that has ancestral Gooby code. It is truly horrific and an affront to whatever machine god (GPT-X?) may judge us in the future. The badness has literally nothing to do with the language. All the bad parts are due to the original team having reached for the most esoteric thing available at the time. I like playing with weird tech shit but there is a time and a place, and that place is not in prod for…

I've personally seen this, it can be pure goddamn cancer. The company hired a very smart charlatan and he convinced them to start a greenfield project in Haskell. Then they need to hire Haskell developers for this specific thing because everyone else only knows Java and Python. Nearly a year later they're barely getting started, but it's getting hyped like you couldn't believe. A lot of sprint planning time starts to…

Not even sure these guys fit the standard mantle of language hyping charlatans. Most of the catastrophic choices were things you could do in any language. With the bonus of no meaningful comments and just committing to master so there's no PR comment history to help the future team's archeology project.

Re: The Functional Programming Hiring Problem

#79

Post by TheDong »

tmpz22 wrote: post #42
Yoric wrote: post #40

Earlier quoted context omitted.

Are then even worse than Go's?

What is bad about encoding/json?

What do you think the following does?

    type Data struct {
     Moon   string `json:"m"`
     Sun    string `jsn:"s"`
    }

    func main() {
     var d Data
 err := json.Unmarshal([]byte(`{"m": "m1", "M": "m2", "Moon": "m3", "s": "s1"}`), &d)
     fmt.Printf("err=%v, data=%+v\n", err, d)
    }
The answer is "Moon:m2 Sun:"

In list form:

1. Specifying unmarshaling shapes isn't checked by the compiler at all, typoing `json:"s"` as `jsn:"s"` should be a compiler error in any sane statically typed language, but in go, struct tags are untyped strings, it does not help you.

2. There are hidden unchangeable unmarsheling rules, like the fact that Moon=m2 is because unmarshaling is case insensitive, even when you specify an exact key name.

3. It's very slow, due to reflection.

4. The API also is not really type safe, things like `json.Unmarshal([]byte, d)` return an error, but should instead not compile because that's a type-error (non-pointer passed to function that requires a pointer).

5. It's slow. It requires a lot of allocation.

6. `json.RawMessage` is subtle and difficult to use

7. It can't stream, so it's very easy to open yourself up to DoS, or to run across json documents `encoding/json` simply cannot handle

I can't think of any other supposedly statically typed language, other than C, where the most commonly used json library integrates so poorly with the language's type system.

Rust's `serde` is what a good well-typed json library looks like.

Re: The Functional Programming Hiring Problem

#80

Post by nicce »

throwawaymaths wrote: post #74

I'm actually suffering from the opposite problem. CTO is a well known Gooby developer. But we wrote everything in C++ because "it will be easier to hire down the line", pulling in well known C++ libraries by various bigcos that actually don't compose together and make a royal mess of the codebase. We've missed every single deadline, and are light years behind where we should be. Honestly we should have written it in…

Now, the correct comment in this context; why not Rust?
Post reply on HN