I think it's smart to start with a high level language which should reduce development time, prove the worth of the application, then switch to a lower level language later.
What was that saying again? Premature optimisation is the root of all evil
A thread going into what Knuth meant by that quote that is usually shortened to "premature optimization is the root of all evil". Or, to rephrase it: don't tire yourself out climbing for the high fruit, but do not ignore the low-hanging fruit. But really I don't even see why "scripting languages" are the particular "high level" languages of choice. Compilers nowadays are good. No one is asking you to drop down to C or C++.
I think that early in development you should be able to spam a lot of hypothesis and quickly test them and check how people interact with your software. Whether your software makes sense is more important than whether it's fast.
People are also highly unpredictable, so it is usually a matter of trial and error, very often their feedback may completely erase wide sets of assumptions you were building your product around.
It's borderline impossible to do it on mature product, but rewriting mature product to something faster is not borderline impossible - it's just very hard.
Note that it doesn't apply if you just program something in accordance from an rfc where everything is predefined.
I think a lot of people are running on facts that are between 10 to 25 years out of date. There was a time when the scripting languages had a very, very large step up in prototyping capability, because the static languages of the time were frankly terrible.
But the static languages have changed, a lot, for the better since then. I now find that when I'm greenfielding something, if I have even a clue how I want to structure it overall, that static languages end up being faster somewhere around a week into the development process. Dynamic languages are superficially easier to refactor, but the refactorings tend to take the form of creating functions that take more and more possible inputs and this corrodes the design over time. Static programs stay working the whole time, and I can easily transform the entire program to take some parameter differently or something and get assurance I'm not missing a code path.
I personally actively avoid dynamic languages for initial development now, for anything that is going to be over a week in size. The false economies are already biting by that point and it gets progressively and generally monotonically worse over time.
This comes from someone who was almost 100% dynamic scripting language in the first 15 years of my career. It's not from lack of understanding of dynamic scripting languages, used at scale.
> static languages end up being faster somewhere around a week into the development process
And when you factor in LLMs being ridiculously good at scaffolding basic apps, the time to reach that turning point will continue to decrease. It takes me time to write out test harness boiler plate, or making a nice dev/staging environment configuration. It is why many languages come with a `mylang create proj` command line tool to automate a basic project. But the custom scaffolding that a LLM can provide will eventually beat any command line project creation tool we can imagine.
This is one of the driving realizations of my point. I've coded in a lot of dynamic languages and a lot of static languages and the distance between their developer experiences are shrinking drastically. I would expect a decent dynamic language expert to become productive in Go very quickly. Rust may be more difficult but again should be totally possible for any competent programmer. Then you add on top of that the fact they will be ramping up using an LLM that can explain the code they are looking at to them, that can provide suggestions on how to approach problems, that can actually write example code, etc.
And then there are all of the benefits of deploying statically compile binaries. Of managing memory layouts precisely. Of taking direct advantage of things like simd when appropriate.
A spectroscope is a handheld optical device which allows you to see the light distribution coming from a light source. Should be able to pick one up for under a hundred bucks.
I've actually looked into this in the past (for measuring the spectra of LED bulbs), but they're significantly more expensive than I expected! Gratings are cheap, but digital models seem to run upwards of $2k. Any suggestions for midrange models would be appreciated!
Save money and go analog! Calibrate against a known spectrum. One example would be a sodium vapour street light but there aren't as many around these days.
The great thing about young people is that they haven't had much time to develop a moral compass. I'd say that makes them perfect for the roles they've been given
Young people tend to be more ideological and ready to fight for what they care. The older you get, the more problems you have (bills, health, children, etc) the less you care imho.
I think there's a middle ground. Very young people are inexperienced but old people are also manipulable too. Probably the most fruitful average ages for doing the right thing are between 40 and 65. I think there are a lot more exceptions for older people than younger ones.
I think it may be, depends on how much of a sense of humour you have. The offensive part suggesting smoking weed in large amounts can make your eyes look half closed. The punchline being Asians are not white males and Asians also (some of them) have eye shapes that do not look like white males.
I'm not a cheerleader of China by any means but the attitude you have towards China is scary. Why does the US have to control the world in order to be safe?
because if we do not, we are falling on the mercy of foreigners who cannot be trusted. China's value system is basically contradictory to ours - most nations' are - so the world will not go our way unless we, or one of a few close allies, are the foremost power.
America has better values than most countries. And Americans should generally trust America more than foreign countries and certainly more than the chinese government.
here are some civilian deaths within china:
- land reform killed 1-4.7 million
- campaign to suppress counterrevolutionaries killed 712k-2mm
- three-anti and five-anti campaigns killed at least 100k
- sufan movement killed ~53k
- anti-rightist campaign killed 550k-2mm
- '59 tibetan uprising killed 87k
- violence in the great chinese famine killed 2.5mm
that's just a sample. this doesn't show the ongoing genocides, the economic colonization of SE asia and africa, the abuses of chinese-supported states (DPRK, burmese junta, naval intervention in libya, etc.)
objectively the American system seems to work out much better and is based on vastly superior principles.
all that aside, I am an American and place the interests of my people ahead of those of foreigners. as such, I will support a world order led by the government most likely to maximize our welfare and very nearly any means needed to preserve that.
> all that aside, I am an American and place the interests of my people ahead of those of foreigners. as such, I will support a world order led by the government most likely to maximize our welfare and very nearly any means needed to preserve that.
The last sentence you said explained what you said above, it also explained many other *Amerikkans* minds
Interestingly, even the most loyal and fervent American imperialists have to find some ridiculous moral excuses.
Despise your hypocrisy, but appreciate your honesty.
Not a question to you personally, but I find it interesting that US Companies were so eager for short term profitability that they basically handed China an obvious manufacturing win for a good few decades.
China is the powerhouse it is today because it was essentially funded by US greed.
It's actually pretty funny (if I look at it like a movie script rather than real life - which is a coping mechanism) watching the US tying itself into pretzel shapes around things like free speech and general values of "freedom" that it's espoused for it's couple of centuries because it's chickens (bats?) have come home to roost, and they're shitting everywhere making people unhealthy.
First thing I would have done is upgrade the version of Gatsby to latest. Did the author try that?
If upgrading is difficult because of 4 years of breaking changes, blame Gatsby for not being backwards compatible. Also blame your original choice of going with a hokey framework.
Speaking of hokey framework: 167 dependencies and 3000 versions of Gatsby in npm.
You could perhaps reframe "blame" as identifying the source of the problem and iunderstand why it can be a useful excercise (aslo none of us here are trying to solve the problem really, just wasting time on the internet). In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue as they don't seem to have any interest in taming the Node dependecy management beast. I've had to dig into Gatsby projects mere months old and it really was like opening a can of worms.
> In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue
I disagree completely. Regardless of what you think of Gatsby, Node versioning is a simple problem that affects nearly every javascript project. It should always be the first thing you check.
I made this dumb obvious mistake again just last week, looking for a little time to audit all my `package.json` files for `engines`.
What was that saying again? Premature optimisation is the root of all evil