> Quit programming. Become a rock star, actor, or corrupt politician. The odds of getting rich in these fields, however slight, are probably better than in programming.
I guess it depends what you would define as rich. If you do not come up with some new hot thing and only count your pay. Then the article is quite right. People really rarely get rich from wage.
I know quite a few developers who are in fact multi-millionaires just from doing exactly that for 10+ years. If you're netting 150k and living on 50k, that's a million in ten years not even counting growth in the market.
Yeah, what would you define as "lots of money"? Here in the midwest, I'd say that >$50k/year would be making more than my entire family combined, so it seems like all software developers do make lots of money to me.
If you stay one place longer than 5 years you are lucky. Every 3-6 years you have to network well or ace the LeetCode for a bunch of strangers. All that stuff gets more tedious once you have kids and a home life.
That’s not to say that it isn’t a good career, but you could do far better with less effort in other fields.
To answer your first question: its software to monitor the execution of a program and produce a mapping from resource usage (usually time-spent) to the source code. This is useful to find the most expensive portions of your application so you can concentrate improvements on them. How exactly to use one would be language-specific, but the general flow is just to loop profiling and addressing problematic code until you're happy with the results. Just gut-checking which exact parts of a program are slow is really hard without prior profiling or very detailed logging (which is a kind of profiling), so they're very important to guide efforts.
This isn't the first AI hype cycle. In the 1980s, Japan's "Fifth Generation Project" was going to create AI software, and thereby ensure Japanese dominance of computing for the foreseeable future. That was, IIRC, Prolog-based (or at least in that style). That... didn't work out.
Before that, there was the AI hype of the 1960s. That was Lisp-based. That failed into the AI winter.
So, yeah. The dream of AI has been around long before 2002. Of course, the definition of "AI language" when the article was written probably does not match the current one...
(Or were you complaining that 2002 was too late for "I've heard that AI is the way to do things"?)
Tangential question: how come "modern" languages (like Go, first release 2009) seem to ignore basic PL Theory, that you learn in the first chapters of any suitable book (see Pierce, "Types and Programming Languges", 2002) ?
I am specifically talking about how the seem to have forgotten (omitted?) parametric polymorphism, the absence of sum types, presence of "nil", lack of type inference?
This is a Go specific problem, which was created with a very explicit anti-intellectualist stance and threw out 40 years of PL theory and practical research.
I don't find it weird at all that simpler languages are more popular/successful.
They're easier to pick up and support the idea of plug and play programmers that is very popular among managers.
Productive as a consequence of the above, maybe; in that more code is written in Go; but certainly not as a quality of the language.
And there's numbness and denial involved. I've been writing Go full time for about a year now at work. Every time I use another language I'm reminded of how much time and energy I'm wasting.
It's not even that it's popular among managers to move people around all the time. That's an awful framework for getting great work done.
People change jobs and you need to choose a language you can either easily hire for or train someone up in. Go fits the second requirement very well, and as more people learn it, starts hitting on the first. I introduced Go at two different companies to great success not because it's my favorite language (I would much prefer Rust, Haskell, Clojure, etc) but in reality, in my role as a leader of a tech org, hiring smart people and getting giving them the means to be productive as soon as possible for however long they want to work with us is key.
Depends on a number of factors. I think GitHub copilot is reducing that trade off a bit more. If the average dev stays somewhere for 2.5 years (our average is quite a bit higher because I tend to think we’re good place to work) - how long are you willing to invest in them learning the new tech (and on top of the, business logic/etc)? The lower the investment number the less you’re willing to dive into rust sans specific technical reasons (which go and elixir would easily meet).
Separately, I don’t buy the notion that a language that has a bit more boilerplate is less productive than one with virtually none.
This is all from a managers perspective, which I suspect is the main reason we disagree.
From a coders perspective, using sub-optimal tools and churning out boilerplate day in and day out makes the difference between keeping a job and looking elsewhere.
Which turns it into a managers problem, because if your developers are not happy, you won't be either in the long run.
> I don't find it weird at all that simpler languages are more popular/successful.
There are diminishing returns on programming features I guess. At a certain level of complexity the difficulty in learning the feature will kill adoption despite the usefulness of the feature - e.g. monads; after months I think I sort of get it ... sort of.
> Every time I use another language I'm reminded of how much time and energy I'm wasting.
Wasting writing Go or wasting writing in the other language? Sorry, just clarifying. I really can't tell which you meant.
Manual loop implementations of basic functional concepts, manual error propagation, finding ways around arbitrary limitations in the name of simplicity, the list goes on and on.
Yeah agreed, especially on the error propagation part. Its especially egregious when trying to send results through channels, I just wish I had the Result enum from rust every time.
Seems like they weren't bad enough to prevent success, plus what were the alternatives? In Javascript's case, maybe Python since it has quite a similar runtime model. But was Python of fhe 2000's really better suited than Javascript at the time? And hasn't Javascript caught up considerably? Same for PHP?
The alternatives never had an opportunity, given that free beer OS with source code (C), only implementatation available (JavaScript), only language available on cheap ISP hosting without additional infrastructure costs (PHP), closed the door to them.
Plenty of opportunities. The alternatives could just have created a mod_php equivalent. I can't imagine ISPs "closing the doors" to newcomer languages, the market should have been competitive enough to allow for penetration.
The thing is that productivity of a language depends on many factors, including many softer ones that are typically forgotten or discounted by language geeks. It also depends on the target audience. In some important ways, PHP was/is brilliant.
A technically brilliant language should be able to recognize the adoption driver mechanisms and build the necessary infrastructure. The point of a language is not (only) to build a theoretically sound framework, but to be an ergonomic vehicle for expression of ideas.
Go was designed for internal use at Google, and one of the primary goals was to reduce compilation time for huge codebases (the size of Google monorepo). For such amount of code even `javac` was too slow for them. To solve this problem, Go was designed to be compiled with 1-pass compiler (similar to Pascal and Modula-2) which makes features like generics and type inference very hard (if not impossible) to implement.
Interestingly, Delphi Pascal has a single pass compiler with generics, though I'm not sure about type inference.
I was under the impression Go originally avoided generics more for a perceived abstract complexity for developers, the idea being they are hard to understand for new recruits.
If that’s true it’s insane that they didn’t try to solve the code explosion problem. Perhaps even a Google-specific DSL that captures their common patterns behind an abstract syntax.
Creating a new general purpose language with such a limited feature set - that it’s likely to result in even more code - seems to be an odd solution.
If a PL allows effective, "good enough" code to be written and maintained efficiently, but doesn't meet your definition of basic PL theory, who is at fault?
"In theory, there's no difference between theory and practice. In practice, there is."
There's more to designing a useful language than is found in Pierce's book. The Go design team had some very specific things they were trying to do, and they did pretty well at doing them, and they produced a language that some people have found to be useful for writing some kinds of software. I'm going to guess that they had a lot more experience at actually writing software than Pierce did. So maybe you shouldn't automatically assume that Pierce is the final word, and that anyone who decides different has to be wrong.
This is tangental, but programming clicked for me once JavaScript introduced me to functional/declarative programming features such as replacing loops with higher order functions (e.g. map) and avoiding mutation.
However, I'm now at a point in my career where I want to get out of the rat race of web development. Are there any programming languages or domains that are "functional/declarative oriented" but actually have jobs? (Note that I don't necessarily mean that I'm dead set on only purely functional programming languages. I would love to get a job working with those, but all I really need is something like that's functional/declarative enough for it to make sense to me.)
Scala is something thats used a lot in data/stream processing and is similar to JS in the functional aspect (more so because there is sum types and pattern matching which is the next awesome thing in functional programming)
> Are there any programming languages or domains that are "functional/declarative oriented" but actually have jobs?
Scala probably has the most, but there's also a lot of people who insist on pretending its Java, so it's hard to say how many of those are really functional codebases.
> Based on this information, you should select one procedural language, one object language, one scripting language, and, possibly, one assembly language which will comprise your core skill set.
but only because realistically you should discard 'assembly language' and swap it for 'browser-supported language' these days. Learning assembly language is basically useless at this point.
Unless you want to get into compiler design or similar it may not be super useful as a career skill, but learning x86 assembly and learning to build a basic CPU from logic gates were two steps along my path to fully grokking how a computer works which I found very useful.
Hard disagree. HN tends to lean toward the browser-programmer crowd, but it's a big world out there, and there are lots of very small computers that don't run a browser. I would go so far as to say that assembly languages in general are a bit like lisps in general: learn one, and even if you never use it, you'll be a better programmer in other languages.
>”Learning assembly language is basically useless at this point.”
I whole heartedly disagree. There’s an entire class of performance tuning you can do to math intensive applications that absolutely require knowledge of assembly to squeeze that last 0.5% out of the machine.
Video Games, Video Editing, Image Editing, Simulations, Scientific applications, all benefit from having some assembly sprinkled into their algorithms for speed.
Because of this, I don’t need crates or packages to do things for me, I’m capable of doing it on my own. I’m capable of building a 64kb demo scene executable. I’m capable of building a hardware accelerated video decoder. I’m capable of parallel vector operations because I can haz assembly. I can disassemble and reassemble binaries, libraries, files, stacks. I can even inject my own code.
If you have no need for speed and efficiency, then I’m sure a browser-based desktop app with some JavaScript will be fine for your use case.
Completely agree with all of that, but I would add that even if you never have to write any assembly at all, just the ability to read your own code in disassembled form is a superpower. It's not hard to learn the basics and, in addition to the ability to debug performance issues, it will forever inoculate you against the "magic compiler" delusion and keep your code somewhat grounded when you actually see what any new abstraction actually turns into.
A lot of people already disagreeing, but my two cents. Reading assembly is crucial. From smart contracts in crypto, to a detailed analysis of the algorithm (Knuth), to analyzing exploits, all requires assembly. It is really one of my weak points, and I noticed several times that I should be better in this. Basically as software engineers we constantly work with weak abstractions, constantly leaking.
54 comments
[ 2.9 ms ] story [ 111 ms ] thread>
> Quit programming. Become a rock star, actor, or corrupt politician. The odds of getting rich in these fields, however slight, are probably better than in programming.
Well, this one is pretty debatable at best.
Now, I'm not saying you'll be a millionaire, but definitely have somewhere in the ballpark of 100k in the bank after 2-3 years.
That’s not to say that it isn’t a good career, but you could do far better with less effort in other fields.
If they’re language specific, then for typescript, Ruby, and Kotlin.
In 2002. Jeez.
Before that, there was the AI hype of the 1960s. That was Lisp-based. That failed into the AI winter.
So, yeah. The dream of AI has been around long before 2002. Of course, the definition of "AI language" when the article was written probably does not match the current one...
(Or were you complaining that 2002 was too late for "I've heard that AI is the way to do things"?)
I am specifically talking about how the seem to have forgotten (omitted?) parametric polymorphism, the absence of sum types, presence of "nil", lack of type inference?
This is a Go specific problem, which was created with a very explicit anti-intellectualist stance and threw out 40 years of PL theory and practical research.
They're easier to pick up and support the idea of plug and play programmers that is very popular among managers.
Productive as a consequence of the above, maybe; in that more code is written in Go; but certainly not as a quality of the language.
And there's numbness and denial involved. I've been writing Go full time for about a year now at work. Every time I use another language I'm reminded of how much time and energy I'm wasting.
People change jobs and you need to choose a language you can either easily hire for or train someone up in. Go fits the second requirement very well, and as more people learn it, starts hitting on the first. I introduced Go at two different companies to great success not because it's my favorite language (I would much prefer Rust, Haskell, Clojure, etc) but in reality, in my role as a leader of a tech org, hiring smart people and getting giving them the means to be productive as soon as possible for however long they want to work with us is key.
It seems to me to be the wrong trade
Separately, I don’t buy the notion that a language that has a bit more boilerplate is less productive than one with virtually none.
From a coders perspective, using sub-optimal tools and churning out boilerplate day in and day out makes the difference between keeping a job and looking elsewhere.
Which turns it into a managers problem, because if your developers are not happy, you won't be either in the long run.
There are diminishing returns on programming features I guess. At a certain level of complexity the difficulty in learning the feature will kill adoption despite the usefulness of the feature - e.g. monads; after months I think I sort of get it ... sort of.
> Every time I use another language I'm reminded of how much time and energy I'm wasting.
Wasting writing Go or wasting writing in the other language? Sorry, just clarifying. I really can't tell which you meant.
Manual loop implementations of basic functional concepts, manual error propagation, finding ways around arbitrary limitations in the name of simplicity, the list goes on and on.
JavaScript, PHP and C are also widely successful, despite their design flaws.
Technical excellence doesn't driver adoption, unfortunely.
The thing is that productivity of a language depends on many factors, including many softer ones that are typically forgotten or discounted by language geeks. It also depends on the target audience. In some important ways, PHP was/is brilliant.
A technically brilliant language should be able to recognize the adoption driver mechanisms and build the necessary infrastructure. The point of a language is not (only) to build a theoretically sound framework, but to be an ergonomic vehicle for expression of ideas.
Go was designed for internal use at Google, and one of the primary goals was to reduce compilation time for huge codebases (the size of Google monorepo). For such amount of code even `javac` was too slow for them. To solve this problem, Go was designed to be compiled with 1-pass compiler (similar to Pascal and Modula-2) which makes features like generics and type inference very hard (if not impossible) to implement.
ISO Modula-2 common extensions (including generics),
https://modula2.awiedemann.de/manual/comp3.html
While using Go is certainly better than plain C, most of its design steams from the authors' bias.
I was under the impression Go originally avoided generics more for a perceived abstract complexity for developers, the idea being they are hard to understand for new recruits.
Creating a new general purpose language with such a limited feature set - that it’s likely to result in even more code - seems to be an odd solution.
There's more to designing a useful language than is found in Pierce's book. The Go design team had some very specific things they were trying to do, and they did pretty well at doing them, and they produced a language that some people have found to be useful for writing some kinds of software. I'm going to guess that they had a lot more experience at actually writing software than Pierce did. So maybe you shouldn't automatically assume that Pierce is the final word, and that anyone who decides different has to be wrong.
However, I'm now at a point in my career where I want to get out of the rat race of web development. Are there any programming languages or domains that are "functional/declarative oriented" but actually have jobs? (Note that I don't necessarily mean that I'm dead set on only purely functional programming languages. I would love to get a job working with those, but all I really need is something like that's functional/declarative enough for it to make sense to me.)
Scala probably has the most, but there's also a lot of people who insist on pretending its Java, so it's hard to say how many of those are really functional codebases.
> Based on this information, you should select one procedural language, one object language, one scripting language, and, possibly, one assembly language which will comprise your core skill set.
but only because realistically you should discard 'assembly language' and swap it for 'browser-supported language' these days. Learning assembly language is basically useless at this point.
Hard disagree. HN tends to lean toward the browser-programmer crowd, but it's a big world out there, and there are lots of very small computers that don't run a browser. I would go so far as to say that assembly languages in general are a bit like lisps in general: learn one, and even if you never use it, you'll be a better programmer in other languages.
I whole heartedly disagree. There’s an entire class of performance tuning you can do to math intensive applications that absolutely require knowledge of assembly to squeeze that last 0.5% out of the machine.
Video Games, Video Editing, Image Editing, Simulations, Scientific applications, all benefit from having some assembly sprinkled into their algorithms for speed.
Because of this, I don’t need crates or packages to do things for me, I’m capable of doing it on my own. I’m capable of building a 64kb demo scene executable. I’m capable of building a hardware accelerated video decoder. I’m capable of parallel vector operations because I can haz assembly. I can disassemble and reassemble binaries, libraries, files, stacks. I can even inject my own code.
If you have no need for speed and efficiency, then I’m sure a browser-based desktop app with some JavaScript will be fine for your use case.