People that work at JS (and 5R and 2S and to a lesser extent FB and Google) have their pick of jobs because they are a hot commodity. The rest of us aren’t so lucky because we have no signal to suggest we are brilliant and likely don’t have the intellectual ability to pass similar coding interviews. It’s tough.
I've completely plateaued on the happiness vs money graph and you couldn't pay me enough at this point to take a job in the finance or defense industry.
1) Are there really that many things you can't do in the world with that salary?
2) Are you choosing a fair group of people to compare yourself with? Yes, you may be at the ABSOLUTE BOTTOM of the top 5%, if you only look at the top 5%. Do you have any non software engineer peers?
I can't save $1.5 million as fast as I want to with this salary (I know people who can live it up and still save $100k a year at Google and trading companies - I'll be lucky to hit $25k max).
>Do you have any non software engineer peers?
Yes. They're all in medical school. The rest I don't really have contact with anymore.
I on the other hand, grew up in a tiny rural town, went to the cheapest state school possible, and now make a healthy 6 figure salary at a no-name company. I don't feel the need to compare myself to anyone; but if I do it's with gratitude. I grew up with people who are now farmers and bakers and baristas and minor fiction authors.
You can choose to compare yourself with people above you, or see how far and healthy you are in the grand scheme of things. Of course that's up to you. If you want to dream big, go for it! Just don't come off as whiny, it's annoying to the rest of the 90% that is be low you on the totem pole.
To be honest, I don't think I did. I just want to be a part of the other bubble really, really, really bad.
I could go on and on about it, and I won't even drop numbers because you won't believe them. The author is a physics PhD and discusses topics very logically and steps back critically analyzes many common cultural behaviors and preconceived notions (what IS retirement, for example) that can help you think about what you really want and the best way to get there.
Judge for yourself but I think his life is a lot more interesting than rich tech kids buying exclusive turnkey vacation packages w/guaranteed great instagram backdrops. Example, walking the docks and joining a sailboat racing team, training for 100 mile bike races, etc.
There's really too much to write here to describe the full philosophy lifestyle, but I encourage you to at least check it out with an open mind. I guarantee you it's not "frugal living", the guy probably has nicer stuff than most people when it comes to clothes, bikes, tools, etc.
Honestly reading your posts in this thread I can tell we're so wildly different when it comes to values that I don't really know if this will resonate with you or not, but again I at least encourage you to check it out, just to see other options for whats out there.
I will go ahead and spoil the "end" of the guy's personal journey, since I think you might be especially interested: Despite having investments that generate over 100% of living expenses, and not having to do anything for anyone, getting to do whatever you want all day, the ends up taking a job as "quant trader/researcher" for the opportunity to solve challenging problems.
http://earlyretirementextreme.com/so-long-and-thanks-for-all...
It's not apparent to me if you want to be a quant, or you want a job that earns a lot of money and is considered prestigious by a certain group of people.
If you had the passion for being a quant regardless of the money, you could be learning and programming in your free time.
If you want the job title more than you enjoy the activity, then I'm sure you could keep studying and practicing and get the job, but I don't think you'll find it satisfying.
If you merely want money for quality of life, stability, security, having F-U money, or anything along those lines, then I'd really want to stress that there are two areas you can work on to achieve that goal. One is earning more money and you seem very focused on that. The other is becoming more efficient with your life. At any point you can make the realization that you've hit a point of diminishing returns in either area, and focus on something else.
I'm not in your shoes, but w/ a salary of 145k at 22 years old, I think you can make the pieces fit to retire in about ~10 years, while spending plenty of money on recreation along the way. Alternatively, I'm sure you can rent/buy/subscribe enough that you spend the next 10 years living paycheck to paycheck. Lifestyle is yours to choose.
The bubble is about to burst and I don't have enough to weather it.
What matters is consistency and time. Invest regularly and long term. Put a little away every week and don’t touch it.
money is only a part of that validation.
PHP suffers from a contempt of the familiar. Lots of programmers of a certain age started off writing PHP poorly before they knew how to properly do their craft (in PHP or otherwise). When you mention PHP, the immediate association for some people is invariably going to be "that really bad PHP 3.5 site I made that one time." Leaving aside any positive or negative points to be made about the language itself, you're dealing with that.
On the other hand, if you work in a generally well regarded but less used language like OCaml IMO you're much more likely to trigger a "huh, I've been meaning to play around with that," or maybe a "gee, if you could pick up an ML while interning you must be pretty adaptable." The relative obscurity might even work in your favor if the person interviewing you is familiar with The Blub Paradox[0] and suspects OCaml might be higher up the language power continuum than the languages they know and you get cred for being a language wonk.
Except in the many thousands of companies that are looking for PHP programmers, where not having it on a resume is damaging.
(I'm in a "microservices architecture" (their word, not mine; I find it cringey, but eh) org where we're expected to deliver features as REST APIs, programming language be damned.)
But I wouldn't call it "dead" per se. At worst, the knowledge easily transfers over to Haskell, Scala or F#. (Sadly these languages all abstract-away most of the knowledge needed to write good, fast Rust code.)
But more importantly ... to business's eyes, Rust is too immature, Scala and F# inherit all the billion-dollar mistakes from their parent VMs, Julia is a data-scientist's tinker-tool and Haskell is too great a paradigm-shift for most programmers. So OCaml is far from being "dead", let alone meriting death.
> But more importantly ... to business's eyes, Rust is too immature, Scala and F# inherit all the billion-dollar mistakes from their parent VMs, Julia is a data-scientist's tinker-tool and Haskell is too great a paradigm-shift for most programmers. So OCaml is far from being "dead", let alone meriting death.
In my previous business, we used Perl, C/C++, Julia, a little Python, and others. We aimed specifically for the best tool for the job. Rarely, if ever, did one language fit the bill, covering everything we need.
I've not used Ocaml, so I can't talk to this. I can state, emphatically, that julia is far more than you indicate. I am rust-curious, though haven't found a good reason to spend time with it at $dayjob. Similar for Perl6, and other more modern languages.
If you advocate a language for the sake of the language, rather than the set of problems you can efficiently express solutions to in that language, I'd argue you might be missing the point of the language. Paraphrasing Iverson on this, language and notation are tools for expressing thoughts. No single notation/language is perfect for all thoughts.
Brutal reductionism is a beautiful tool for cutting away all the fluff; seeing where different things are really multiple sides of the same die; and asking the young excited pimply-faced advocate of the newest fad, a rhetorical "so what?".
Want to elaborate that? Afaik, neither of them tries to imitate mathematics.
> namely a good combination of footgun protection and expressiveness
None of those languages have parameterised modules, Ocaml is far more expressive in some fronts.
Generally speaking, "f x" instead of "f(x)" meaning function application, types not being able to serve as namespaces for functions, arguments' types in signatures being specified separately from their names, and most importantly the preference of first-class operator symbols over function- or method-calls.
* * * * *
For example, I find this much more difficult to read (from Hakyll):
-- | Sort pages chronologically. Uses the same method as 'dateField' for
-- extracting the date.
chronological :: MonadMetadata m, Traversable t => t (Item a) -> m (t (Item a))
chronological =
sortByM $ getItemUTC defaultTimeLocale . itemIdentifier
where
sortByM :: (Monad m, Traversable t, Ord k) => (a -> m k) -> t a -> m (t a)
sortByM f xs = liftM (map fst . sortBy (comparing snd)) $
mapM (\x -> liftM (x,) (f x)) xs
trait TraversableExt<Element> /* ... */ {
fn sort_by_m<M: Monad, K: Ord>(self, f: impl Fn(Element) -> M<K>) -> M<Self> {
self = self.map_m(|x| f(x).fmap(|key| (x,key)))?;
self.sort_by_key(|(x,key)| key).map(|(x,key)| x)
}
}
fn chronological<T: Traversible, A>(items: T<Item<A>>) -> impl MonadMetadata<T<Item<A>>> {
items.sort_by_m(|i| i.identifier().getUTC(Default::default))
}
Using lots of operators is certainly something that could be seen as more mathematical but then I guess that makes APL much more mathematical than Haskell and ocaml and c++ and perl combined. I don’t think that counts as mathematical but it is a difference of style.
For specifying signatures this is surely a style thing. In type theory, types are normally put right next to the values and so in this respect Haskell and ocaml are not mathematical. I say this is a style thing as one can write types separately from variables, next to them, or not at all.
For “types not being a namespace” I’ll give you that criticism for Haskell (but also for C) and maybe for ocaml but recall the common idiom of calling all types “t” and putting them in their own modules with relevant functions. I don’t see how this is more mathematical.
My general complaint is that these aren’t differences on a more/less “mathematical” spectrum. The only mathematical things are that ocaml/Haskell are closer to lots of the fashionable PLT research than C and that research is certainly mathematical. Also Haskell people tend to fetishise category theory and abstract algebra so lots of the code that’s written is sort-of mathematical. Haskell also suffers from readability problems mainly due to the people who write Haskell and what they like rather than the language itself.
Some of what functors do can be done with typeclasses/traits. Eg a functor might take a module with a type and compare function and produce a type of maps fron that type. Meanwhile in Haskell/Rust you get the compare function from a typeclass/trait.
On the other hand you can only have one trait/typeclass implementation per type which requires newtype wrapper awkwardness if you want an alternative. Another problem is that traits tend to be basically small but functors can be big. Eg let’s say you want to write an application for transferring files over various protocols. You might implement a module per protocol which would include things like the type for the configuration, how to read the config, how to make a connection, how to pool connections, how to request a file, how to get chunks of it and so on. These things may not fit so well into a nice typeclass and some Haskell people certainly don’t like typeclasses that don’t correspond to mathematical things. In ocaml the file transferring program might be based on a fuynctor applied to each protocol.
A second thing rust/Haskell don’t have is a way to make a typeclass at runtime whereas one can do that in ocaml, e.g. it’s basically impossible to make a safe type for arithmetic mod n in Haskell/rust if n must be known at runtime. It is actually possible with Reflect in Haskell but that is horrific. It would be nice if one could do something like:
withMod : Integral a => a -> (forall b. (Integral b, Injects a b) => b -> c) -> c
withMod (m:a) f = f (Modm m) where
newtype Modm = Modm a
instance Num Modm where ...
instance Integral Modm where ...
instance Injects a Modm where
inject = Modm
You inspired me to learn OCaml because I've never thought of it as a language that's capable of expressing things that Haskell just can't.
Also (perhaps this is encompassed by your statement already) there is ReasonML[0]. Switching over from the JS Quickstart to the OCaml Quickstart, one finds the very first line:
> Since Reason is just another syntax for OCaml, [...]
Side note: just finished a small project in ReasonML and it was a lovely experience. As someone who has been using Flow for gradually typed JS for a while now, I would totally recommend at least playing with it.
Albeit it is Google who start then leave to die more languages than I can count on the fingers of one hand.
OCaml is very far from dead though.
1) https://ocaml.org/meetings/ocaml/2017/slides__2017__anil-mad...
2) https://www.infoq.com/presentations/ocaml-browser-iot/
It seems that there is constant work on the tooling part of the language, and that multicore would be (on the far) horizon.
[citation needed]