I agree. Text works. Now we get to argue over ASCII, Latin-1, ISO, Unicode, tabs vs spaces, emojis versus emoticons, CR/LF vs CR vs LF, byte stream or record format, CamelCase or pythonCase or unixcase, but thankfully we don't have to decide on vim vs emacs as those are external tools.
Anything with the word "manifesto" makes me doubt it. It's a political statement made by people with big egos who want other people to die for their beliefs. As such, manifestos have no place in engineering.
Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally. I came back 6 months later once only to find out that nothing had really happened in all of that time that was useful to the actual product being built.
So we had to create a demo version of the project, all while doing Agile. Afterwords, we rip out 50% of the code because it's shoddy mockup needed only for the demo. Meanwhile the management sees a good response to the demo and claim that we're going to be shipping soon and that orders are showing up.
There can not possibly be a potentially shippable product on day one, for ANY new project, unless that project is "add features to an existing product".
Because I'm being reponsible to the needs of the project, I end up being unable to do the tasks (stories) assigned during the development period (sprint). If I was irresponsible I would do just my parts in the sprint and tell all the competing needs to bugger off.
Why "waterfall"? Why is every Agile evangelist so uptight about "waterfall", do they honestly think that there are only two possible methodologies in the world?
When it works though it is with the sorts of projects where waterfall and other methods won't work well anyway. Short projects. Ie, you've got a working web site, with an existing customer base, and now you want to add a feature. Agile lets you do that. And you need something similar to it anyway because you can't take down your site for long periods, so the continuous integration/testing is vital. But for projects that are normally big enough to require planning start to lose value from Agile.
Agile is failing in some areas, surviving in others. One snag is that Agile is a cult, pure and simple. If you vehemently disagree, then perhaps consider that you may be a cultist.
And the Agile cultists also believe there are only two world views: Agile versus Waterfall. Which is ridiculous, because the vast majority of developers use neither and instead have a hybrid approach from many different modesl including some ad-hoc methods. I know people who work as contractors who've said every single company they've been at use a different method, even those who claim to use Agile all use it in extremely different ways. When you are told essentially "do you really want to go back to Waterfall" then you know you're talking to a cultist.
Agile is pushed by its promoters as ideal for all types of projects. It does work well in some sorts of projects, where everything can be divided into tiny one or two week chunks, but it fails horribly where you need months of work for some features and lots of upfront design with large teams that need to coordinate. For example, taking an existing web design and maintaining it is easy with Agile, but designing an entire product from scratch, including hardware, software, and services will find Agile to be a frustration. What I have seen happen a lot is that there's a lot of old style design behind the scenes by the designers but then Agile is used up-front by the coders; each sprint picks out portions of the grand plan to work on, features are split into tiny two week slivers and so forth.
Don't forget the Agile industry here too. People whose high paying jobs are to teach Agile, to facilitate Agile, to be paid scrumm masters rather than developers, and so forth. I've seen no other development style that involves so many paid outsiders, most of whom are evangelists.
Of course there are good things with Agile but failing to acknowledge the bad things is not being objective.
Right now I'm on sprint number 10 for my feature. I get pressure to finish up the feature, but then at the same time there is pressure to stop working on it and instead deal with the unexpected emergencies. At the start I thought it was simpler than it really was and my design (which took longer than a sprint to think up) turned out to have flaws. It's embedded so the whole continual testing thing is extremely difficult, you can't put in unit tests when you don't even have enough memory to fit in the basics. And ideally, that two week sprint really should be 3 days of implementation only so that you have time for all the documentation, testing, handoff, training, integration, figuring out the obscure parts that come with no documentation, etc.
The ultimate thing that Agile is doing for me is making me work longer hours than I ever have in my life. That's the goal I think, it's why managers love it. Ie, I have to give a two week estimate of what I can get done. Now I feel personally responsible to get things done. The deadline is no longer an external deadline by people unfamiliar with what needs to be done but instead it is a self-imposed deadline. And self-imposed means I want to get it done so that I don't look foolish. Other people are waiting for it to be done so that they can do their part. If I do ask for more time I get glared at. And what happens now is that there is a deadline EVERY TWO WEEKS. It is ALWAYS crunch time! And there is still behind the scenes the high level deadline from the executives that can not slip.
I agree here. Especially when encountering new stuff or concepts, most documentation is unhelpful. Ie, learning how to use PGP using only their reference manuals is daunting; or a newcomer learning how to use Berkeley style sockets using only man pages leads to many mistakes.
Well sure, they have it. But there are snags to watch out for. Ie, the classic problem is what to do if your inheritance tree is not a strict tree so that the same ancestor class can be reached through more than one path through the inheritance hierarchy.
Ie, A inherits from B and C, and both B and C inherit from Object. Thus Object is a inherited from twice. So then if there's a method in Object, modified by both B and C, which inheritance path do you take? More complex, if you've got a "super" type of call then what traversal order is done? For example, if your language has constructors then what order are the constructors called and is the Object constructor called twice or only once?
Different OO languages give different answers to these questions. Worse still, there are very good and rational arguments to make for each answer so that you can't just dismiss them out of hand, saying that the C++ method is superior to CLOS for example. People do academic papers on this stuff because it's not simple.
Not so sure about multiple inheritance. Sure, it's convenient. Or it seems convenient until there's something messy with it and workarounds are needed to make it work as expected. There have been 30 years of struggling with this concept and it's still a pain (though Python has a nice solution I think). Consider on the other hand that Smalltalk does not have multiple inheritance and yet it's the classic examplar of an extremely high level OO language, it doesn't even have interfaces or need them.
No, generally I upgrade because the old versions aren't available. I'm NOT using the new features, but the whole thing is slower than it was, but on a faster computer it seems the same. It's like there's a speed budget, that apps have to run at a certain responsiveness level, and features are added until it starts to affect that responsiveness.
Ie, Adobe Reader. Used to be small, fast, easy to use. Today it's huge, bloated, and with a stupid UI. But it does exactly the same thing it always did - for me. I want it to read documents only, never write to them, never to allow me to add my signature, I don't want to deal with encrypted documents (the only reason I'm forced to use newer versions), etc. It has security updates because they've been stupid and started adding too much to it instead of being a small simple read-only program. Mozilla's PDF viewer works just as well, or the OSX Preview, or other alternatives.
I had a boss who would call consultants who program that way as "cowboys". As in, they ride into town, shoot their guns a lot, ride off again into the sunset, and the town folks are left scratching their head wandering what just happened.
I'm pretty sure OpenSSL has been fixed. They had a patch within a few days, and they've even bumped the version number since then to 1.0.2. Maybe you're thinking of commercial software which is sometimes slow to push out fixes.
And yet today, C is still one of the top languages that operating systems are written in. Even some operating systems written mostly in C++ have a few C files tossed in. The reason I think is that C is just high enough level to be convenient but low level enough to let you do the stuff that's needed with the machine. So there's not much pressure for higher level languages to evolve for writing operating systems in.
So C won't be made obsolete by higher level languages. But it may be dethroned by other similarly low level languages with added improvements, like D or Rust or...
And for systems level coding, you do need freedom to do what you want much of the time. This is because you're breaking the rules a lot, you're doing the unexpected. Ie, you flush the cach, switch context, etc. You don't have a language run time system to implement stuff for you, because you yourself are creating the run time system. You do your own error handling and stack unwinding. Sure, it's good to have compiler warnings telling you that two pointers may not be compatible with each other, but a systems programming language should have a way to get around that without reverting to assembler.
Whoops I replied to the wrong message instead of this one (stupid UI). But sometimes I need to shoot towards my foot. And there is stuff I need to do that C can do and many other languages just don't want to let you do. Now Ada can let you do a lot of that systems level stuff, but for some reason it didn't get that popular. I'm using C now and I need to use it, though I could do with C++ as a back up plan, but Ada would require a massive retraining effort but would also work.
Sometimes the compiler thinks I'm wrong when I am not wrong.
C does compile down to very small code with small memory usage, if you write your code that way. Sometimes that's more important than other factors in a language. It's also great because many compilers allow inline assembler, it's a waste of space to have to do a function call just to access assembler.
Sometimes you want to point the gun straight down and pull the trigger. Some languages are like nannies in absolutely prohibiting that action, even if you've written lines of code just before that point to verify that your foot is out of the way and proper kevlar footgear is being worn. Sure, if you're writing high level application code, then maybe you don't want to make typecasting easy.
But at the systems level you absolutely need to do things that any good compiler will be squeamish about; I absolutely want to cast my byte pointer to a word pointer, I want to make sure it doesn't optimize away my other pointer which is pointing to a hardware register, I'm treating the signed integer as unsigned on purpose, and so forth.
C isn't used only because of legacy. There's a lot of brand new code in C, especially for small machines. The only real competition is C++, and people are nervous about that for many reasons. C++ is bulkier if you're not careful because there's a lot of stuff hidden behind the scenes, it has more run time library requirements which is painful if you're writing your own, some compilers have had absolutely byzantine error messages, and so forth. It's unfair though, since C++ on it's own does not cause bloat, you also need C++ programmers for that. With self disclipline you can get C++ code almost as small as C code.
The fastest way to get the programming done is not necessarily the best way to get the program done. Programming fast is only important if you've got a tight deadline and you also have room to be sloppy. Even then time should probably be scheduled to go back and fix it up later.
Normally training wheels come off once you learn to ride that bike. But in many languages the training wheels are permanent. I do wish that more people who call themselves programmers or engineers actually understood how computers work. Then we wouldn't need faster computers every 5 years just to keep running the same programs at the same speed.
I'm pulling my hair out working hard to get a high quality security system into place on a device where it barely fits, only to see an article that says "ticking time bomb!" We're not all idiots. I suspect most of us aren't. The security we're using requires actual knowledge to use, it's not for some home users or casual people, it doesn't have passwords but it has certificate exchange, no phone will ever talk to them, etc.
Problem is that the media and purveyors of panic are focusing on the dumb end of the market, the consumer devices, the vendors jumping on the bandwagon just to get the IoT label, etc.
Slashdot Mirror
MS Office is also impractical for 95%+ of its users.
I agree. Text works. Now we get to argue over ASCII, Latin-1, ISO, Unicode, tabs vs spaces, emojis versus emoticons, CR/LF vs CR vs LF, byte stream or record format, CamelCase or pythonCase or unixcase, but thankfully we don't have to decide on vim vs emacs as those are external tools.
Anything with the word "manifesto" makes me doubt it. It's a political statement made by people with big egos who want other people to die for their beliefs. As such, manifestos have no place in engineering.
Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally. I came back 6 months later once only to find out that nothing had really happened in all of that time that was useful to the actual product being built.
So we had to create a demo version of the project, all while doing Agile. Afterwords, we rip out 50% of the code because it's shoddy mockup needed only for the demo. Meanwhile the management sees a good response to the demo and claim that we're going to be shipping soon and that orders are showing up.
There can not possibly be a potentially shippable product on day one, for ANY new project, unless that project is "add features to an existing product".
Because I'm being reponsible to the needs of the project, I end up being unable to do the tasks (stories) assigned during the development period (sprint). If I was irresponsible I would do just my parts in the sprint and tell all the competing needs to bugger off.
They're both made up funny words, stolen from a sports context and used by people who don't do sports. It's just a part of the Agile liturgy.
Why "waterfall"? Why is every Agile evangelist so uptight about "waterfall", do they honestly think that there are only two possible methodologies in the world?
When it works though it is with the sorts of projects where waterfall and other methods won't work well anyway. Short projects. Ie, you've got a working web site, with an existing customer base, and now you want to add a feature. Agile lets you do that. And you need something similar to it anyway because you can't take down your site for long periods, so the continuous integration/testing is vital. But for projects that are normally big enough to require planning start to lose value from Agile.
Agile is failing in some areas, surviving in others. One snag is that Agile is a cult, pure and simple. If you vehemently disagree, then perhaps consider that you may be a cultist.
And the Agile cultists also believe there are only two world views: Agile versus Waterfall. Which is ridiculous, because the vast majority of developers use neither and instead have a hybrid approach from many different modesl including some ad-hoc methods. I know people who work as contractors who've said every single company they've been at use a different method, even those who claim to use Agile all use it in extremely different ways. When you are told essentially "do you really want to go back to Waterfall" then you know you're talking to a cultist.
Agile is pushed by its promoters as ideal for all types of projects. It does work well in some sorts of projects, where everything can be divided into tiny one or two week chunks, but it fails horribly where you need months of work for some features and lots of upfront design with large teams that need to coordinate. For example, taking an existing web design and maintaining it is easy with Agile, but designing an entire product from scratch, including hardware, software, and services will find Agile to be a frustration. What I have seen happen a lot is that there's a lot of old style design behind the scenes by the designers but then Agile is used up-front by the coders; each sprint picks out portions of the grand plan to work on, features are split into tiny two week slivers and so forth.
Don't forget the Agile industry here too. People whose high paying jobs are to teach Agile, to facilitate Agile, to be paid scrumm masters rather than developers, and so forth. I've seen no other development style that involves so many paid outsiders, most of whom are evangelists.
Of course there are good things with Agile but failing to acknowledge the bad things is not being objective.
Right now I'm on sprint number 10 for my feature. I get pressure to finish up the feature, but then at the same time there is pressure to stop working on it and instead deal with the unexpected emergencies. At the start I thought it was simpler than it really was and my design (which took longer than a sprint to think up) turned out to have flaws. It's embedded so the whole continual testing thing is extremely difficult, you can't put in unit tests when you don't even have enough memory to fit in the basics. And ideally, that two week sprint really should be 3 days of implementation only so that you have time for all the documentation, testing, handoff, training, integration, figuring out the obscure parts that come with no documentation, etc.
The ultimate thing that Agile is doing for me is making me work longer hours than I ever have in my life. That's the goal I think, it's why managers love it. Ie, I have to give a two week estimate of what I can get done. Now I feel personally responsible to get things done. The deadline is no longer an external deadline by people unfamiliar with what needs to be done but instead it is a self-imposed deadline. And self-imposed means I want to get it done so that I don't look foolish. Other people are waiting for it to be done so that they can do their part. If I do ask for more time I get glared at. And what happens now is that there is a deadline EVERY TWO WEEKS. It is ALWAYS crunch time! And there is still behind the scenes the high level deadline from the executives that can not slip.
I agree here. Especially when encountering new stuff or concepts, most documentation is unhelpful. Ie, learning how to use PGP using only their reference manuals is daunting; or a newcomer learning how to use Berkeley style sockets using only man pages leads to many mistakes.
Well sure, they have it. But there are snags to watch out for. Ie, the classic problem is what to do if your inheritance tree is not a strict tree so that the same ancestor class can be reached through more than one path through the inheritance hierarchy.
Ie, A inherits from B and C, and both B and C inherit from Object. Thus Object is a inherited from twice. So then if there's a method in Object, modified by both B and C, which inheritance path do you take? More complex, if you've got a "super" type of call then what traversal order is done? For example, if your language has constructors then what order are the constructors called and is the Object constructor called twice or only once?
Different OO languages give different answers to these questions. Worse still, there are very good and rational arguments to make for each answer so that you can't just dismiss them out of hand, saying that the C++ method is superior to CLOS for example. People do academic papers on this stuff because it's not simple.
And certainly, if the GPA is only 2.5 then don't list it. Leaving it off lets others assume it is higher.
Not so sure about multiple inheritance. Sure, it's convenient. Or it seems convenient until there's something messy with it and workarounds are needed to make it work as expected. There have been 30 years of struggling with this concept and it's still a pain (though Python has a nice solution I think). Consider on the other hand that Smalltalk does not have multiple inheritance and yet it's the classic examplar of an extremely high level OO language, it doesn't even have interfaces or need them.
No, generally I upgrade because the old versions aren't available. I'm NOT using the new features, but the whole thing is slower than it was, but on a faster computer it seems the same. It's like there's a speed budget, that apps have to run at a certain responsiveness level, and features are added until it starts to affect that responsiveness.
Ie, Adobe Reader. Used to be small, fast, easy to use. Today it's huge, bloated, and with a stupid UI. But it does exactly the same thing it always did - for me. I want it to read documents only, never write to them, never to allow me to add my signature, I don't want to deal with encrypted documents (the only reason I'm forced to use newer versions), etc. It has security updates because they've been stupid and started adding too much to it instead of being a small simple read-only program. Mozilla's PDF viewer works just as well, or the OSX Preview, or other alternatives.
I had a boss who would call consultants who program that way as "cowboys". As in, they ride into town, shoot their guns a lot, ride off again into the sunset, and the town folks are left scratching their head wandering what just happened.
The ultimate faith based security?
I don't. but...
I'm pretty sure OpenSSL has been fixed. They had a patch within a few days, and they've even bumped the version number since then to 1.0.2. Maybe you're thinking of commercial software which is sometimes slow to push out fixes.
And yet today, C is still one of the top languages that operating systems are written in. Even some operating systems written mostly in C++ have a few C files tossed in. The reason I think is that C is just high enough level to be convenient but low level enough to let you do the stuff that's needed with the machine. So there's not much pressure for higher level languages to evolve for writing operating systems in.
So C won't be made obsolete by higher level languages. But it may be dethroned by other similarly low level languages with added improvements, like D or Rust or...
And for systems level coding, you do need freedom to do what you want much of the time. This is because you're breaking the rules a lot, you're doing the unexpected. Ie, you flush the cach, switch context, etc. You don't have a language run time system to implement stuff for you, because you yourself are creating the run time system. You do your own error handling and stack unwinding. Sure, it's good to have compiler warnings telling you that two pointers may not be compatible with each other, but a systems programming language should have a way to get around that without reverting to assembler.
Whoops I replied to the wrong message instead of this one (stupid UI). But sometimes I need to shoot towards my foot. And there is stuff I need to do that C can do and many other languages just don't want to let you do. Now Ada can let you do a lot of that systems level stuff, but for some reason it didn't get that popular. I'm using C now and I need to use it, though I could do with C++ as a back up plan, but Ada would require a massive retraining effort but would also work.
Sometimes the compiler thinks I'm wrong when I am not wrong.
C does compile down to very small code with small memory usage, if you write your code that way. Sometimes that's more important than other factors in a language. It's also great because many compilers allow inline assembler, it's a waste of space to have to do a function call just to access assembler.
Sometimes you want to point the gun straight down and pull the trigger. Some languages are like nannies in absolutely prohibiting that action, even if you've written lines of code just before that point to verify that your foot is out of the way and proper kevlar footgear is being worn. Sure, if you're writing high level application code, then maybe you don't want to make typecasting easy.
But at the systems level you absolutely need to do things that any good compiler will be squeamish about; I absolutely want to cast my byte pointer to a word pointer, I want to make sure it doesn't optimize away my other pointer which is pointing to a hardware register, I'm treating the signed integer as unsigned on purpose, and so forth.
C isn't used only because of legacy. There's a lot of brand new code in C, especially for small machines. The only real competition is C++, and people are nervous about that for many reasons. C++ is bulkier if you're not careful because there's a lot of stuff hidden behind the scenes, it has more run time library requirements which is painful if you're writing your own, some compilers have had absolutely byzantine error messages, and so forth. It's unfair though, since C++ on it's own does not cause bloat, you also need C++ programmers for that. With self disclipline you can get C++ code almost as small as C code.
The fastest way to get the programming done is not necessarily the best way to get the program done. Programming fast is only important if you've got a tight deadline and you also have room to be sloppy. Even then time should probably be scheduled to go back and fix it up later.
Normally training wheels come off once you learn to ride that bike. But in many languages the training wheels are permanent.
I do wish that more people who call themselves programmers or engineers actually understood how computers work. Then we wouldn't need faster computers every 5 years just to keep running the same programs at the same speed.
I'm pulling my hair out working hard to get a high quality security system into place on a device where it barely fits, only to see an article that says "ticking time bomb!" We're not all idiots. I suspect most of us aren't. The security we're using requires actual knowledge to use, it's not for some home users or casual people, it doesn't have passwords but it has certificate exchange, no phone will ever talk to them, etc.
Problem is that the media and purveyors of panic are focusing on the dumb end of the market, the consumer devices, the vendors jumping on the bandwagon just to get the IoT label, etc.