Because content is orthogonal to form. Development at its core is virtually pure content. The form, the fonts, the graphics, the "pixels". It's noise with regards to the task at hand. It's not useless, because surely we have eyes and need to witness text on the screen (for now), but it is orthogonal to the main axis of resistance we are trying to overcome (for which we get paid).
People that don't understand the separation between content and form cannot separate between data and rendering, between models and views. They stuff JS in CSS and CSS in databases.
In short, they make shitty architects and are to be shunned from programming important software in general. No offense.
That's more ageism than anything else. I mean surely real "programmers" know the new hotness "ghsfgusdfu", right? How could you live without?
I know companies running on SVN and they're fine. In fact, it's a better fit for them. Yes, Git is not always superior.
I'll give you a helpful concept to navigate these issues: "Cargo culting refers to the practice of imitating the superficial aspects of a process or practice without understanding the underlying logic or reasons behind it. This phenomenon is often seen in software development, where developers may adopt certain coding styles or methodologies without grasping their true purpose."
Git is over 20 years old at this point. If somebody is in their 60s now, they were in their 40s when it came out. This is not about age. They must have slept on it for a long time.
Nobody expects an engineer to be a git expert, but if a senior software engineer has heard of git only yesterday or don't have a vague concept of how DVCSs like hg or git work (DAG of commits), then something has gone very wrong.
Maybe there are use cases where SVN is superior (I can't come up with any but they may exist), and maybe engineers in that industry really are so specialized that they never get around to working on anything else!
But maybe it's because nobody else is willing to hire them.
If you are not in an environment where it is being actively used it is not something you'll pick up. Not every programmer is on HN or being cool with blogs etc. I agree not knowing about source control at all is a .. different matter. Also, 20 years is less impressive once you subtract the time it wasn't popular. Even if it was 20 years, it is still not impressive. Perhaps if you are 15-30, but to older folks it's like a drop in the bucket.
Many people are not familiar with "git" and don't have to be. Picking up "git" is a one afternoon type of thing but the parent did not mention timelines. It was just about "knowing" git and I pushed back on that.
There are so, so many tools you guys on here find indispensable that don't actually get used by vast swaths of people in the field. I sometimes wonder where all you guys work.
If you're actively looking for a job, you should have some familiarity with the common dev stack when you're looking. Today you should be comfortable working on a Mac, know Bash / Zsh, a little bit of Vim for SSHing, git, docker, react, postgres, etc.
If you don't, spend a few weeks before you start your search. You're almost definitely going to need them. Unless you're in a niche where the common stack is different.
This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing, you're going to stumble without cursory knowledge. You don't need to be an expert in it all…
> This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing,
Then I don't apply. I'm not interested in working with garbage tech.
Interesting! I'd love to hear what type of work you do where you can get away without any of those because frankly I think most of those are pretty garbage too.
Postgres is decent for a free ($$$) database, although it's lack of clustered indexes and in-place updates (its MVCC approach) sucks for many use cases. I find it a sensible default but not the best at any one use case.
Python, frankly, sucks nowawadays. Maybe it had its time, but there are so many better lingos now. It's got type hints that are ignored, really bad patterns ("dependency injection" that's really just the singleton pattern, FastAPI encourages you to open a db connection and a transaction at the front of every request and commit at the end while you're making other requests, writing to disk, etc), and it's slow in both user experience and runtime (no real parallelism).
But generally I have to make some trades to get a great job. I love Go, personally, and the incredible simplicity it encourages.
Seriously, if you'd be willing to share, I'd love to hear what you do!
Fair enough that I did not mention any timeline. And could’ve been general with “VCS”. And you are absolutely correct, that basics of some of these tools can be learnt in an afternoon.
In fact the industry i work in we don’t have git, but something similar to SVN (and proprietary, expensive and pathetic UI/UX)
Since, I am not in software industry, I won’t comment on whether such people might survive for more than 5 years without knowing about ‘VCS’.
However, I have slightly died inside when some Computer science students (graduate school, mind you) were using google drive with manually created timestamps as a backup strategy. The submission for this entire semester long actual project was on Github. as a final single commit uploaded a day before. (And no this wasn’t a squashed commit from a different repo.)
There might be a blurry line between people not sharpening their auxiliary tools vs never using or being slightly curious about them.
I am more of a glamour and bling on my tools person, and I don’t expect every engineer to derive the same pleasure that I derive just from tinkering with them; however, does make me wonder if there is a point when such an approach to not fully caring about simplifying your workflow (aka being lazy), might spill over into making poor engineering decision?
It's possible to always work for big tech companies and never use some popular tools like git. Not a good thing either, but it doesn't mean they're wannabe programmers, cause I've seen those too.
One is that it solves all problems once instead of various times in various levels of quality on various types of systems. Windows, GTK, Qt, FLTK, [100 others].. not to mention most "native UI framework" delegate to the underlying OS so they don't "solve" anything.
Electron is not a novel approach or "technology" of achieving cross-platform UI. It's literally a Chromium browser plus a Node.js runtime, using web-stack to impersonate desktop application. None of these tools have been designed to solve UI pain points.
Closest thing to what you're describing is Flutter, which is a UI framework designed from ground up for modern UI app needs, without delegating much to OS level.
I believe what's missing is not just data. That'd only grant it capabilities that upgrade it to a "record" type of entity. I believe an OOP object is more than a record. It's missing behavior triggered by messages. For an object to pass or receive a message we need to have a model of a message and that requires the notion of a sender and receiver, both objects again. Seems circular, but I'm sure it could be made to work if you properly define everything. Anyway, to my mind perhaps the minimal model of an object is not at all _one object_ but a _relation_ between two or more objects showcasing the minimal "message passing" semantics.
Weird take, but inheritance could be included if you accept something can inherit from itself. A is a type of A, I mean it doesn't strike me as wrong, but it is unconventional.
Behavior is a good clue. The current model, even with data, lacks behavior. It has a method, which is like a message we send to it. But it does not seem to give it enough behavior, even though we don't make any assumptions about its complexity.
Or maybe it could give it behavior if it were like that:
class Aaaa
[some data]
method handle(message, ...)
[some code]
This construction implies there are multiple messages. "Multiple" is the key difference. The part that was missing in the original sketch is a second method:
Now this is an object. For example, it can be a random number generator: we initialize it and then read next numbers. Or it could be a timer: we initialize it and then read the value. We do not need a fully object-oriented environment for that; there is a plenty of such things in C and other non-OOP systems.
Such a thing surely has some behavior and this is exactly what we use. We are not interested in the internal data much. In fact the internal data of an object play exactly the same role as a function stack frame: it is a private slice of memory a computation keeps for itself because this is how it works. As in knitting the size of the manipulator is tiny compared to the final result and to do anything substantial we need a place to keep stuff around until we are done. And we need to be sure data stay were we've put them, hence encapsulation.
So an object is very much like a function, it is a computation that uses some memory to do its job. It is different in that in an object the computation runs step-by-step guided by external events. A function is like an object that gets the whole sequence of events at once, runs from start to finish and in the end discards the working memory so we tend to forget it exists. An object runs from message to message and keeps the working memory, which we see as "object data". This is why objects arise naturally in areas like user interface where events are truly external. But an object is actually a primary form of computation: if you can process a single event, you can use it to process a sequence; but if you can only process the whole sequence, you cannot just switch to processing single events. There are many similarities with closures, coroutines and such; I'd say they are different ways to express the same principle.
(This also means that objects are naturally mutable. Immutable objects are an aberration that arose because we've got here in a very roundabout way.)
So you say an object is like a computation stretched over time and a function that same computation but compressed into a single invocation? Like an object is a computation whose execution is suspended between messages? I can see how that ties closures, co-routines, etc together. They are all machinery to preserve execution state across time.
Generally you could say computation is traversal through a space of states and in that frame objects expose the intermediate states, the guts so to speak, and functions hide them and only expose the in-out mapping.
I feel these are two poles of some deeper principle. Ah man, I'm not well-read enough to go further than this. I kind of worry why most developers are not deeply familiar with this material because these things will inform many foundational choices we make in system architecture and we'd definitely could use some better shared vocabulary and argumentative machinery than mere opinions and "that's how we always do it".
Yes, this is exactly what I'm saying. Objects, closures, co-routines and eventually state machines, which was the first concept, I think, all revolve around the same core thing.
We keep returning to it because this is the natural way to do computation using a machine, but we also try to escape because it is rather hard for a human. We like the functional form more: it looks sequential and goes nicely from start to end. With objects we quickly lose our way in a soup of small parts.
This is known as the object lambda duality which Guy Steele wrote about. If you think hard enough, you reach this core idea that objects and closures are just yin and yang, inseparable.
So why have objects when you have closures? I believe that by externalising the decision on how to behave when a method (selector) is called, into a concept like a vtable, you can apply greater levels of optimisations.
In other words, a closure is a object that encapsulates (keeps private) the list of function pointers it is able to respond to. This is not necessary, and Piumarta (linked by me elsewhere in this thread) shows you can reach this generalisation well within the OOP system, by making vtables themselves objects which respond to a lookup method that returns a function pointer.
People that don't understand the separation between content and form cannot separate between data and rendering, between models and views. They stuff JS in CSS and CSS in databases.
In short, they make shitty architects and are to be shunned from programming important software in general. No offense.