You won't have any problems filling positions at all... if you are willing to pay through the nose and not complain that you are now sleeping in the very bed you made.

I'm a bit surprised that https://xkcd.com/606/ doesn't seem to be mentioned yet.

Meh. Glad you are having a good experience with the LLMs. I like them for helping with testing and code coverage but a couple of times recently I've had to come up with a bit of specialized code and (after) when I ask my LLM overlord to accomplish the same task it gets really close but has a bug or two. My problem is that even modifying the prompt to give it more clues and even ask it to avoid the bug with specific suggestions it will spit out the code with the same bug. If I can't ask it for a picture of a glass of wine full to the brim what good is it?

Big push on AI right before I hit college. Just after it was all "AI's failed promises!". Then deep-learning and GANs gave it a fresh lease on life and now that it has achieved many more wonders, it's broken again. I'll catch y'all in another 30 years to follow up on this thread when it will be "sentient in 5 years!" but then broken again.

The one thing that would have brought me back to Microsoft. Oh well.

Challenge accepted. The history of the history of science.

Wow. Really?

Functional programming.

1. Prefer non-mutable data. No more action at a distance bugs. Hand off a reference to your data structure and don't have to care. Replay any data transform at any point as a unique structure.
2. Prefer a defined and well known API often involving transforms that take a function as an argument to provide the predicate (e.g., filter), transform (e.g., map), aggregation (e.g., foldLeft/Right), or whatever building block.
3. Prefer data structures that you can reason about based on a well-known set of patterns. (Best quote ever: "You say `patterns' and everyone is warm and fuzzy. You say `monad' and every loses their f-ing minds.)

Given (2) in a language you'll often see in a language that functions are first-class data.

Functional programming is just (a set of) best-practices. It's scary when the big words are new. Once you use it a bit you'll wonder why when you say, "use a flatMap", folks freak out because all you've said is, "You are transforming the elements of some container into values that are themselves an instance of the same container but you want to flatten everything back from nested containers. [E.g., Container is C with element type A; thus C[A]. You've run a transform that will create C[C[A]] but want to end up with C[A] at the end]." Now you could say that second part but that's a lot of words. Because of points (2) and (3) above we just say, "use a flatMap" (or however you spell `bind` in your language of choice).

Nothing to see here. Please move along. (And yes. I like functional programming. A lot.)

1) Do you need a degree or to dive into the math to make effective use of the language? No. Like any programming language you can just learn the patterns and apply them. That said, like any programming language, if you learn the math behind why it works you can make more effective use of the language. (You are probably using monoids, functors, monads, and maybe applicative functors in any large program. Not knowing what those are doesn't mean you aren't using them.)

2) Would I recommend switching?

I having been programming professionally for 31 years. I have been programming Scala since 2010. I have taught about a dozen people the language. Much like, "Should I quite my day job to put all my time into my startup?", the answer is probably, "not right now". If you can get the same or better pay, under the same or better conditions, then obviously yes, make the switch. Otherwise if the language interests you (same answer for the startup) then work on it in your spare time with your day job giving you the security you need to expand your horizons. As a programmer learning new languages will make you a better programmer. Learning languages like Scala or Haskell which lean so heavily into functional programming and their higher-kinded type systems will definitely expand your knowledge. Additionally you'll then be able to decide if a switch is worth it FOR YOU rather than relying on getting a useful answer from a infinite number of monkeys banging on an infinite number of keyboards.

All that said no company would pay the price I would demand to code in Java again.

Being in the middle of taking a Coursera course right now I can state that the content is still free if you audit the course. Auditing a course gives you access to the lectures, coursework, and the forums. You cannot submit coursework for a grade, nor receive a final grade and certificate (if you pass) unless you have paid for the course.

Having taken several of the original free courses I was concerned at first but once I read through all the fine print I think it's a fine way to monetize the system. Free for those that want information and a charge for those that want proof of having taken the course.

This again. Every language is poor if used poorly. Every technology is poor if used poorly. And the opposite is also true. The trick to getting good technology if used correctly is that some technologies require more discipline on the part of the developer/implementer to use well.

In my company we aggressively mentor everyone so the language (Scala) doesn't have a lot of dark corners. We also mentor the mathematics (I see monoids. They're everywhere!) so that when someone comes across a bit of advanced code almost indistinguishable from magic they don't think "it's magic. I can't touch it." It takes an extra dozen weeks or so but the return is huge (like taking a couple of thousand lines of code and turning it into 80, all nicely immutable to kill those nasty action-at-a-distance bugs).

There's nothing wrong with Perl that isn't also wrong with every other language. They are a tool. If you choose not to learn how to use a tool appropriately don't make the mistake of thinking the tools you know how to use well are intrinsically better.

First, don't go it alone. If you can't find a few friends that you can convince that you are on to something with whatever product ideas you have then you aren't on to something.

Software development is a team sport. Even if the other players are you in 6 months. Have coding standards. Have have your IDE or some program enforce them. Write documentation. Use version control. Use a bug tracking system. (Yeah, all that stuff you've read is best-practice... it got published as best-practice for a reason.) As a startup select a "major" language but for scripting just accept that any of perl, python, ruby, bash are fine. Train, mentor, and grow your people. You want really good generalists at this stage and not experts that can't also do ops, admin, front-line, etc. Using open-source software is a force multiplier. If you are going to extend OSS just make sure that your product value is in the data you are generating and not the code (since you'll be giving the code away for free).

You'll want to find people at least as good as you are for raising money, marketing, sales, product development, and IT (assuming you'll be CTO/VP Eng and leading development; if not find a CTO [tech strategist to put in front of investors and give you something coherent as far as technology goes], and/or a VP Eng [developer+manager who can wrangle the cats and makes sure product gets delivered when product is supposed to be delivered]. Coming from the tech side of things do NOT undervalue marketing, sales, and your CEO. The better mousetrap will not sell itself. At the same time while a great sales guy can sell snow to Eskimos they won't pay a lot for it. Find/build a team that covers each others weaknesses.

Gonna stop here. Could go on like this for a while since this is what I've been living the past 4 years.

Blogs in no particular order: Joel on Software, Paul Graham, any other 2-3 of the top tech incubators in the country (Google em).

Finally, ignore anything above that doesn't make sense for the business you are running.

It's not being an expert at some particular language that ends up paying. It's being an expert. You will always have to play your cards right but there are high paying jobs in any of the languages. Figure out the style you like, become an expert in one of its mainline languages, play your cards right, profit.

First all the unicode operators of scalaz have names as well. Second, just what language is the functional library scalaz written in? I'll bet *that* would be a pretty good functional language to work with.

It's Scala. They left out pattern matching and didn't drive the monadic nature of common programming collections through the collection classes. You can leave out the monads (although the first time you want to convert the contents of an Optional value via a function returning an Option you'll wish they hadn't) but leaving out pattern matching was a plain and simple misstep.

I guess I did miss the point. Since in my family it was all about how misguided the Vietnam war was and talks of student sit ins and such. Fonda was naive but she was, I think, on the correct side of the argument.

But I guess you missed the point too. Holder stated [1] that the Executive Branch wasn't going to make a blanket statement hemming in the Executive to use drones during such events as Peal Harbor and 9/11. So what we've got is a temper tantrum which compares two of the most epic events in US history where the power of the Executive would have swept pretty much anything before it to a single Vietnam war protester who happened to get a lot of attention because she was a celebrity over whom the Executive could only exert the most minor of authority. If a drone were to have killed Jane Fonda it would have been an obvious criminal action. If a drone had shot down one of the remaining jets after the towers were hit it would have been a justified use of a military force to avoid a larger death toll. Trying to compare the two is simply trying to derail the stated response to (Rand's) original question.

[1] http://paul.senate.gov/files/documents/BrennanHolderResponse.pdf