But most people in our profession get to choose their job, don't they? Why would a Python project hire a rust programmer? Why would someone who hates Python work on a Python project? I feel the same way. Sporadic use of type hints is nice, and I use it sometimes for reference, like a very succinct comment. But if I want a typed language, Go, Dart, C or even Java are right there.
Because sometimes people choose their jobs prioritizing pay, location, title, company, project, role, coworkers, etc. and the language they will primarily use (or even use on a secondary basis) is a lower priority concern.
In my case, I have, in the pursuit of my engineering goals, had to dig into a Python component that I did not normally work on or intend to work on. I am thankful it had type hints.
But none of these reasons should trigger a "I'm going to change this fundamental thing about x because I don't like it".
I don't have anything against typing. I just get annoyed when it gets out of control in a language it wasn't part of to begin with. Just look at how complex typescript typing is to see where it can go.
Used pragmatically it's fine. When it's out of control we might as well switch to another language.
The entire ML ecosystem is in python these days. I had a project at work that was Python because of that. Type hints saved me a lot of work in easing other people’s code.
> Why would a Python project hire a rust programmer?
> But most people in our profession get to choose their job, don't they?
Let's say someone has only worked in Python professionally but dislikes it. They spent nights & weekends learning Rust. Now they want a Rust job. Because a Rust project would not hire a Python programmer, this person who hates Python is stuck working on Python projects.
It's attitudes exactly like "Why would a Python project hire a Rust programmer?" that keep people stuck in languages they don't hate. Those attitudes are the reason a senior software engineer with over a decade in the field can't switch tech stacks. Without that attitude, job postings would be written for programmers, not python programmers, and the job market would be better for it.
Even if we have some choice of jobs, your model only works if programmers have language as their only or most important requirement when job searching. There are lots of factors that might make a job more or less desirable aside from programming language, like location, salary, team, business domain, and so on.
Seems pretty plausible that someone can dislike python and still like a job because it checks other boxes.
> most people in our profession get to choose their job
Choose, yes, but from a finite set.
> Men make their own history, but they do not make it as they please; they do not make it under self-selected circumstances, but under circumstances existing already, given and transmitted from the past. The tradition of all dead generations weighs like a nightmare on the brains of the living.
— Karl Marx, "The 18th Brumaire of Louis Bonaparte"
The Vic-20 was my first computer, so it has a special place in my heart. It was a hand-me-down from an aunt at the time when the C64 was the star of the show, and I only had 2 games for it. My only option was to learn how to program. It was so crude, that the thought of running something like Elite on it never even crossed my mind. I'm shocked someone actually went on and did that. Wow!
I did the same, learning basic along the way. I got a dot matrix printer and learned how to send print statements to the printer. I wrote an essay for school and printed it out line by line using print statements. Good times.
It does require a 32k expansion which almost nobody had - I don’t remember pricing from the era but I would guess 32k of static ram (the VIC did not have a DRAM controller) would get you more than halfway to a c64
In 1985 8KB 6264 = $7, 1986 same chip $4. So ram alone would be $15-30, then add pcb case and margins and we are around $100, more than VIC-20 itself was worth at the time.
I did too, and am. Unfortunately my dad bought two (another for sister) and so we had to "suffer" with black and white TV monitors. May be also why we didn't get a 64, although it may have been too early for that.
I didn't learn that assembly language programming was a thing until maybe fifteen years later, and didn't know the 20 could be programmed that way until another decade later after that. Nor that it supported a modem, etc. So feel a bit cheated.
If you don't over complicate it, React apps are very simple. Emphasis on the very. The opposite is also correct. If you DO over complicate it, React apps are extremely complicated.
Also, the SPA model works great for some apps and badly for others. This blanket ruling of "do x and not y because x worked for us and y didn't" is just bad advice.
Simplicity is relative. I wouldn't call having to reimplement basic browser features like forms simple compared to slapping Turbo on server-rendered HTML (which took me ~50 LOC last I did so on Pocket SQL).
It is. And it's very much domain dependant. One of my projects is a CRM application, which is a SPA. Years ago, I had a similar incarnation of that projects as a "traditional" html+js model. It works much much better as an SPA on many levels. It's a complex app with a lot of UI elements. A simpler application might not benefit from being an SPA. So it all depends. I'm just allergic to that style of "X is dead to me so X must be dead to you".
That's interesting because a CRM sounds like a strong use case for server-rendered HTML: Relatively low interactivity outside of form handling, which is consistently a weak point for SPAs. I wonder how different your experience would have been back then if you had modern browser APIs and something like Turbo, because the manner in which you go about the JS makes a huge difference. I would not advocate that people use HTMX for example, which strikes me as just being inline JS.
An SPA is actually very suitable for this type of app. It was simple forms in the 00s, but it's not that anymore.
First, in my case, the back end is an API (python). It is also serving mobile apps, and 3rd party integrations. Turbo is more suitable, if I'm not mistaken, for Javascript based applications.
Second, my CRM is fast. The UI is snappy and there is little lag, which is something people comment on a lot.
And third, there are many components there where a page reload will break things - for example, when you perform a telephone call from the browser. You can still navigate the data, without reloading the page and cutting the call.
It's never simple, and NEVER EVER one size fits all. I'm saying this after about 30 years of doing this job commercially.
Turbo is just a front-end library it doesn't matter what your backend stack is. You can do all of that with a MPA approach, including partial DOM updates, with just the JSON API for your mobile apps being the missing part simply due to not needing it for the browser implementation. Serializing JSON on the backend and transforming it into HTML via React should always be slower than just sending the same HTML over the wire. I'll have to benchmark Pocket SQL to get frontend numbers, but it is perceptibly instant with requests taking single-digit ms, so it's not like the server-rendering part of it is slow. I'm glad the SPA approach worked out back then! The point I'm making is that MPAs are worth another try with modern tooling.
I really wanted, and tried so hard to like this game. But it just didn't work for me. This visualisation though it very nice and I do wonder what was used to create the graph canvas UI?
Before I learned about SSH identities, I used to have a shell script sourced into my bashrc with a hashmap containing all my hosts and full connect string, so that I could `ssh hostname` like one does with SSH identities.
I really truly hope that one day optional types are introduced to the EcmaScript/JavaScript spec. My only reason for saying that, and I know it's the unpopular view, is that I actually LIKE JavaScript and think TypeScript is a mess of over complicated concepts, trying to do too much and feels sometimes it's in competition with itself for how verbose and complex it can be. So I'm hoping that the introduction of types to JavaScipt will be the same death spiral seen with the likes of CoffeeScript (remember that?).
Optional typing is one of my favorite features of groovy.
Explicit typing also helps show where code needs to be explicitly performant and of course where type strictness is valuable.
I'm assuming of course that types in js flavors has performance advantages a la asm.js, but admittedly I haven't tracked JavaScript evolution that closely.
If it isn't typed then that helps clue the programmer that looser dynamic techniques being used.
I'm not arguing against types. I'm arguing against an extremely convoluted type system that is so complex it's practically a language on it's own. And it's sole existence is to make a dynamic language not dynamic.
In the early 90s I (and a friend) wrote a text adventure game based on the Punk scene at the time. It was my first piece of software that I released. This was a period of time where I used to print and keep my emails. This was done on TADS, was called "The Broken String" and was/is on the IFArchive. I can't say THIS was my favourite game, but it does have a sentimental hold over me. The premise was that in order to "save the scene" you must form a new band, going through the city looking for band members.
Other than that I was quite fond of the Infocom and Magnetic Scrolls games. Most of them were great. The games that I absolutely adored were all the text based Sierra games. All of them. I was quite upset when they removed the text parser.
