91–100 of 140 posts
Earlier quoted context omitted.
I think Newtonsoft is quite ok, but the MS library lacks a lot.
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.
There’s plenty of mainstream programming languages that get the job done just fine without the hiring problems.
I’m 100% certain you don’t “need” gooby.
Hiring for gooby doesn’t scale, so unless your company’s goal is to stay small, don’t use gooby. And “the CTO likes it” isn’t good enough reason.
The original gooby loving CTO always leaves to spread more gooby to other companies and the owners of the company are left with a long term problem.
Just use the garden variety languages that there is a large talent pool for.
Do your gooby at home on your personal projects.
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…
> 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…
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. Do that on your own time. You're being paid hundreds of thousands dollars to deliver business value - so do that. Build mathematical towers on your own time.
It's like paying someone by the day to paint your house and they paint the Mona Lisa in white paint on white and take 3x as long because it's more artistically beautiful even if the end result is just an all white painted house.
"Don't you see the deeper hidden artistic structure!?"
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…
I'm always surprised when I see this approach to hiring. I have a lot of Haskell in the codebase at my current company. It hrs never occured to me to try to hire from the "Haskell community" we always hire from our product community because tech is easier to teach than product.
The blog post has some reference numbers embedded, but I cannot find the references below. (Did I miss something?) Specifically, the author hinted about a language and a company for #1. I guess this is Jane Street with OCaml? To be clear, you can make any insane language choice that you wish, so long as you pay so much money that no one will care. Exhibit A: Jane Street with OCaml
Regarding sidenote #1, I actually very deliberately did not mention the language or company ;) Here's the full text of the sidenote, if you're still unable to get it rendering:
> I'm not going to name the language itself, because this post would just turn into a flame war over that language specifically, and I definitely don't want to cast shade on any language/community in particular. I'm also kind of hoping that the most annoying people read this and think, "Ah, of course he's talking about that language over there! This criticism obviously doesn't apply to my perfect and favorite language!" Regardless, I feel that the thesis and content of this post applies pretty evenly to most functional programming languages.
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…
> But then I saw the downside: these type-happy programmers almost never tested anything.
In 2024 it is irresponsible to start that company off using gooby. There’s plenty of mainstream programming languages that get the job done just fine without the hiring problems. I’m 100% certain you don’t “need” gooby. Hiring for gooby doesn’t scale, so unless your company’s goal is to stay small, don’t use gooby. And “the CTO likes it” isn’t good enough reason. The original gooby loving CTO always leaves to spread…
Earlier quoted context omitted.
> 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…
The issue with emacs is the sheer number of variables. And the fact they're global. That leads you to do stuff you shouldn't do. But the principles are essentially the same. And in CL, you can snapshot the current state of your program to a file. Then restart later, instead of reloading the environment from the code.
A quick demo: https://youtu.be/jBBS4FeY7XM
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…
And that's why we switch languages constantly. For some problems, some languages suck a little less.