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

121–130 of 140 posts

Re: The Functional Programming Hiring Problem

#121

Post by neonsunset »

rqtwteye wrote: post #119
neonsunset wrote: post #115

Earlier quoted context omitted.

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.

No, it never does. There are better containers than dynamic, that do not have its performance drawbacks and have way better UX. The fact that this does not raise an eyebrow is a legitimate concern over the state of the codebase that uses it!

Re: The Functional Programming Hiring Problem

#122

Post by nequo »

apprentice7 wrote: post #88
presentation wrote: post #84

Earlier quoted context omitted.

It’s a spectrum, it’s multidimensional and it changes over time though. I love myself computers and probably more so earlier in my career than now, but I also like influencing people (often through code, with a focus less on algorithmic elegance but instead more on setting patterns, tooling, and APIs that influence how others build around them); and I also enjoy the challenge of aligning the pleasure of a juicy piece…

Hello! I'm just starting my career as a dev now and I am definitely more drawn to academia and research than to the business world. Could you point me to some resources where I can learn more about companies or projects that work researching CS/programming topics? Thank you in advance.

If you are drawn to research, look at the affiliations of the authors of papers that you like. There are pockets like INRIA, Galois, Tarides, but it really depends on what research you are interested in.

Re: The Functional Programming Hiring Problem

#123

Post by BeetleB »

Const-me wrote: post #105
BeetleB wrote: post #71

Earlier quoted context omitted.

Ok. For anyone struggling with the second, the answers should be: Lack of libraries. Lack of good tools.

My favourite languages are C# and C++, and sometimes I interview developers to work with them. Saying these languages are lacking libraries or good tools is unreasonable.

True, but it's trivial to come up with things to dislike in C++ :-)

Re: The Functional Programming Hiring Problem

#124

Post by kiviuq »

That's the thing, though. Gooby is just a means to an end; the ultimate end goal of your company is to write software that is useful to people and makes money. For the zealots, however, Gooby is the end in and of itself.

So, where's the difference? One doesn't care about what they sell as longs it makes them money, the other as long they have fun.

Re: The Functional Programming Hiring Problem

#125

Post by Const-me »

BeetleB wrote: post #123
Const-me wrote: post #105

Earlier quoted context omitted.

My favourite languages are C# and C++, and sometimes I interview developers to work with them. Saying these languages are lacking libraries or good tools is unreasonable.

True, but it's trivial to come up with things to dislike in C++ :-)

Great point on C++, but it’s harder for C#. The language and ecosystem are IMO pretty good.

I only hate that Microsoft stopped shipping modern .NET runtime with Windows. A few annoying things though, like the recent push towards AOT compilation (IMO strictly worse that JIT), and the lack of a good first-party cross platform GUI frameworks (for example Microsoft could compile d2d1.dll with DXVK, reimplement dwrite.dll API on top of FreeType / HarfBuzz, and copy-paste UWP).

Re: The Functional Programming Hiring Problem

#126

Post by BoiledCabbage »

tome wrote: post #117
BoiledCabbage wrote: post #94

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…

> "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.

> Mathematics has proved invaluable in many domains of business.

As has art.

Re: The Functional Programming Hiring Problem

#127

Post by tome »

BoiledCabbage wrote: post #126
tome wrote: post #117

Earlier quoted context omitted.

> "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.

> Mathematics has proved invaluable in many domains of business. As has art.

Intriguing! Can you give some examples? And maybe contrast their preponderance to mathematical examples?

Re: The Functional Programming Hiring Problem

#128

Post by aleph_minus_one »

presentation wrote: post #84
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…

It’s a spectrum, it’s multidimensional and it changes over time though. I love myself computers and probably more so earlier in my career than now, but I also like influencing people (often through code, with a focus less on algorithmic elegance but instead more on setting patterns, tooling, and APIs that influence how others build around them); and I also enjoy the challenge of aligning the pleasure of a juicy piece…

> That said, if you really are 100% motivated by abstract technical challenges, then maybe academia is more for you than industry is.

Of course. Such people very typically attempt to get a foothold in academia. The central reason why they nevertheless leave academia is because of the precarious job situation.

Re: The Functional Programming Hiring Problem

#129

Post by xigoi »

mike_hearn wrote: post #110
PheonixPharts wrote: post #20

Is this written from a different time line were TypeScript doesn't exist? I have a long history of doing FP in a bunch of the traditional FP languages (Scheme/Haskell/etc). Ended up working at a young startup with equally young employees awhile back and was sort of surprised to see that the long heralded fantasy of cranky FP enthusiasts has, for better or worse, come true in Type Script. I saw a generation of new pro…

That's not a TypeScript issue. I've encountered the same problem of not testing things properly in other languages. There's a definite mindset amongst some programmers that if it compiles and the unit tests pass, then it must work. I think a lot of less experienced devs have read too many blog posts on PL theory/testing and don't realize how many bugs are just not going to get caught by such techniques. You really do…

What’s wrong with top-level functions (as opposed to methods)? Is there a meaningful difference between foo(bar) and bar.foo()?

Re: The Functional Programming Hiring Problem

#130

Post by mike_hearn »

xigoi wrote: post #129
mike_hearn wrote: post #110

Earlier quoted context omitted.

That's not a TypeScript issue. I've encountered the same problem of not testing things properly in other languages. There's a definite mindset amongst some programmers that if it compiles and the unit tests pass, then it must work. I think a lot of less experienced devs have read too many blog posts on PL theory/testing and don't realize how many bugs are just not going to get caught by such techniques. You really do…

What’s wrong with top-level functions (as opposed to methods)? Is there a meaningful difference between foo(bar) and bar.foo()?

Same reasons JS has modules that don't export everything, and for the same reason that React reinvented OOP under a different syntax with function components. Encapsulation, API design, runtimes and IDEs all work a lot better if the tools are aware of the link between the data and the code that's manipulating it.
Post reply on HN