81–90 of 94 posts
There are many hard problems in computer science and software engineering. As it turns out, the solution to these problems is spider charts. Finally, we'll be able to write distributed low-latency software that interacts with both legacy systems and browsers with complete end-to-end type safety, provable correctness and fault tolerance! In half the time, at half the cost! With spider charts.
Earlier quoted context omitted.
It depends on what you are working on. I would argue front end is more like architecture and back end is more like civil engineering.
I struggle to come up with a distinction between the two, with respect to the original post. The design work that goes into programming is largely irrespective of the problem. In fact, if you stick to common design methodologies you often won't even see a significant difference between "front end" and "back end" work – and I might even suggest the line is completely arbitrary.
Earlier quoted context omitted.
The best way I've heard this described is this: Engineering has a well-defined constant you're always building against: gravity. In software, you choose your gravity, and it changes all the time. Sometimes there are twelve gravities. Sometimes there are different types, and they interact in complex unpredictable ways. In short, it is a much more difficult problem. But personally I believe we can reach a meta-engineer…
Software is not all made up out of thin air -- you do not 'choose your own gravity'. The equivalent of phyical laws in software are computational/algorithmical, logical laws. For example, sorting cannot be done faster than O(n log n) -- that is as hard and objective as anything physical. (In fact, one would think it is even harder in some sense, since it is so purely logical.). Software is built within algorithmic co…
Earlier quoted context omitted.
This leads to a few questions, though. First, if bridges were built just fine in the 50s, why do they build them differently nowdays? Second, why is the maintenance cost of bridges decidedly non-trivial? Third, is there any software that is that old that still works fine? For the first question, I would only be offering speculation. Google and friends can give pretty good references. For the second, a quick google gi…
Tex is not 50 years old. Also, it's borderline unusable to anyone who hasn't mastered what "underfilled hbox" means and the like. Internally it's so unsustainable that people are trying to start from scratch with full rewrites. However, because there actually isn't a standard for latex beyond "how tex" renders it, it's a horrific undertaking. TeX is far from "just working". Onto bridges, just because they build them…
TeX is not 50, I had not meant to imply it was. Just that it is a relatively old piece of software that has had virtually no maintenance compared to many other pieces of software.
Could it have used an overhaul? It is certainly debatable. However, Knuth has had massive success in keeping it working without worrying about use cases that just were not the aim of software.
To continue the comparison with bridges, it is not uncommon for them to have restrictions saying that large trucks can not cross them. This is not a recommendation, it is a requirement. In the software world, many would have modified TeX to do such things as typeset documents miles wide. Because, generality! Or some such.
And the concerns you have about people not knowing what an "underfilled hbox" means is simply a lack of training. I would be surprised if anyone I work with below the age of 25 has even heard of TeX, much less read the documentation for it. Heck, I could probably raise that to 40.
So, my assertion is that the fact that TeX is still very much usable shows that it was "well engineered." Would it require somewhat expensive training? Sure, but how is that any different than the maintenance of bridges?
Earlier quoted context omitted.
Sorry, I shouldn't have thrown in the quip on FPGAs. It really is a complete non-sequitor. I think a very neat topic, but didn't belong here. I don't accept that generics are somehow an automatic win for languages. I do like them somewhat, myself, but I don't think there has been compelling evidence that they can be used to great effect in building embedded systems. Consider, at the low level, the majority of the cod…
If you look at surveys ,c++ ,as shitty as it may be, is used a lot around the industry.And the fact that ARM have chosen it for the mbed on which they plan to build an operating system around for IOT chips, shows it's value for mcu's, at least in some segments. The other data point regarding rust is the huge excitement in the embedded community.
And do not mistake what I'm saying as that I think rust isn't as good as c. Even better, in many ways. My question is specifically if people today will be able to accomplish better things because of the language. I'm doubtful.
Most of the biggest accomplishments in embedded space comes down to the massive gains in the silicon. Most of which is dominated by advances in boolean chain evaluation to make faster circuits. Wider, sure, but also faster. (At least, that is my understanding... I'll admit I am no authority on this.)
Earlier quoted context omitted.
Libraries sure. I'm talking about production software.
Yes, that's an entirely different thing. But I would rather compare a production software system to something bit more dynamic, like a nuclear plant or an airplane than a bridge.
So, then should we assume that software is like road building? No, rather I would assert that there are some pieces of the road that are more isolated from dangerous use and changes than others. In software, we have some of that, too, but not to nearly the extent. We are often holding up pitchforks to rewrite everything.
Earlier quoted context omitted.
Sorry, I shouldn't have thrown in the quip on FPGAs. It really is a complete non-sequitor. I think a very neat topic, but didn't belong here. I don't accept that generics are somehow an automatic win for languages. I do like them somewhat, myself, but I don't think there has been compelling evidence that they can be used to great effect in building embedded systems. Consider, at the low level, the majority of the cod…
GCC is moving from C to C++ and from what I can tell GCC developers seem to think it is an improvement, and GCC suffered from inadequacies of C.
Second, I don't think anyone would argue that the biggest thing spurring movement in GCC is the success of clang.
Earlier quoted context omitted.
I struggle to come up with a distinction between the two, with respect to the original post. The design work that goes into programming is largely irrespective of the problem. In fact, if you stick to common design methodologies you often won't even see a significant difference between "front end" and "back end" work – and I might even suggest the line is completely arbitrary.
I'm thinking about things like animations & css work. That is almost entirely aesthetic, and thus more like architecture. Even when I'm writing the entire app, I draw a pretty clear distinction between 'front-end'/UI and 'back-end' type work.
Software engineering was taken more seriously 20 years ago than it is now. There have been some notable successes of rigorous development, but they're not well known. Here are two in wide use. The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for…
"The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, th…
It's not like we can't design very elegant, robust, reliable software, you know. We just can't find anybody to pay for us to retool the whole stack (and I do mean the whole stack, since we're only as strong as our weakest link) while the current ad hoc solution operates within acceptable parameters. The guy who wrote this paper, in my opinion, is missing two really bedrock principles of "pure" engineering-- manufactu…
I've been increasingly wondering if the cost of building reliable, effective, and secure software in all the places we use it... is just more than we can afford on a social level (like a higher percentage of GDP). With that price mostly being people, of course. When we say "We don't know how to build good software", does that really just mean "We don't know how to build good software cheaply enough for the businesses…