131–140 of 242 posts
Life isn't supposed to be beautiful or elegant or simple or perfect.
If an entrepreneur can make money while improving the parts of life (no matter how small) that others benefit from, what can possibly be the issue?
I'd like to buy Zack a drink, because all of this is obvious to those poor shmucks among us that handle the support end of things (also known as the "shit end"). I've been saying a lot of the same things for years. I'm tired of it now; I'm starting to give up, because it's obvious there isn't a programmer out there that gives a damn. You can try telling them that there's something wrong with software -- something fun…
"Just about everybody knows that all our software is imperfect crap on top of imperfect crap, from top to bottom. Everybody, when met with a new codebase above a certain size, thinks they could do better if they started over and did it "properly this time". Everybody can look at a simple thing like a submit form in a web browser, and sigh at the inefficiencies in the whole stack of getting what they type at the keyboard onto the wire in TCP frames, the massive amount of work and edifices of enormous complexity putting together the tooling and build systems and source control and global coordination of teams and the whole lot of it, soup to nuts, into a working system to do the most trivial of work.
"But this is not a new or interesting realization by any means. It's not hard to point almost anywhere in the system and think up better ways of doing it. Pointing it out without some prescription for fixing it is idle; and suggesting that it will be fixed by wholesale replacement by another complex system is, IMO, fantasy."
(Things probably only seemed like they worked in the old days because you hadn't realized what was going on in the sausage factory; or it was an almost useless piece of hardware whose software did almost nothing, owing to its simplicity.)
I'd like to buy Zack a drink, because all of this is obvious to those poor shmucks among us that handle the support end of things (also known as the "shit end"). I've been saying a lot of the same things for years. I'm tired of it now; I'm starting to give up, because it's obvious there isn't a programmer out there that gives a damn. You can try telling them that there's something wrong with software -- something fun…
The alternative used to be: report a bug. Put it in bugzilla. I've reported thousands of bugs. Maybe 30-50% of them used to be fixed. Nowadays I'd be pushing it to say 5%.
I've gone to report GNOME or Ubuntu bugs, only to find that the problem already has a bug report from 5 years ago. The bugs are still open and unfixed, with a poor sap adding a "me too" comment every few months.
I'd like to buy Zack a drink, because all of this is obvious to those poor shmucks among us that handle the support end of things (also known as the "shit end"). I've been saying a lot of the same things for years. I'm tired of it now; I'm starting to give up, because it's obvious there isn't a programmer out there that gives a damn. You can try telling them that there's something wrong with software -- something fun…
I remember spending hours moving around jumpers to set DMA and IRQ. Only to find out that the only free IRQ was #9 and bloody Packard Bells sometimes didn't have a frikkin' 9 because that batch of boards was $2 cheaper that month...
I remember when it wasn't pretty and it took ridiculous efforts to make it work even a little. Now I mostly jam a USB thing in the side and it goes. There has been much improvement.
I'm actually a little psyched by it all. This just happens to be a really hard problem that arrived at humanity's doorstep before we were really evolved enough to make much of it. It might mean we're ahead of the game, and it almost certainly means that the best is still yet to come.
Earlier quoted context omitted.
>allowed_users You can pay someone to implement this, as well as any other missing AD features, then open source it so no-one has to implement it again. The original devs that did much of the reverse-engineering work on Samba have since moved on to much more rewarding work. That work will essentially never be done again, nor be improved upon until financial incentives are introduced. Much of the work on Samba since h…
Thank you (seriously) for demonstrating the part where I said, "but they'd rather tell you why you're wrong rather than really listen to why you're frustrated." > ...as well as any other missing AD features... This isn't exactly a feature, it's a core part of AD permissions. Samba 4 was developed for the purpose of taking on server roles in an AD environment. > We are not your servants, we are people. Give value, get…
Hey everyone thanks for your comments, I have learned a lot today. For all I complain about the state of technology, it's remarkable that I am using it to communicate with some of the most amazing people in the world. You just can't make this stuff up. I think that maybe it's time to stop taking the pain and do something about it. The only part I've never been able to figure out is how to earn enough income and maint…
I'll give you my current high-level pet peeve for free:
While programming, it is so incredibly easy to miss something, to not be entirely thorough.
I think a lot of problems originate from the fact that, even for an experienced programmer, it is hard to get a feel for what a function actually does, including all the corner cases. Especially if someone else wrote it, or you wrote it a long time ago. Yes, you can read the program text, and encounter a lot of logical expressions, evaluations, etc. Fitting it all into your head can be difficult and takes quite some time. Code as text format is quite limited and slow to parse deeply in your brain.
I'm sure that is possible for a tool (some kind of uber-IDE) to help with this, for the compiler to 'explore' what happens inside the function (as that's what a compiler does). But what it can't do is show it to you in a useful way.
Some vague ideas around this:
- test cases: a lot of work in writing test cases is simply mechanical. You want to evaluate all the code paths, verify assertions and function input/output. There are initiatives like (Microsoft) Pex that attempt this. If you have auto-generated unit test-cases that explore the corner cases you get more feel for what a program does and what might still be wrong.
- code verification: computers are incredibly fast, and can understand the code that we type instantly. With post/preconditions and assertions, it could be possible to find bugs and overseen cases while we type in the background by random/structured "brute force" fuzzing (let the monkey loose) or modeling analytically. Imagine the hours of debugging saved.
- graphical languages: pictures sometimes say more than words. Would also remove the "mental overhead" of worrying about specific superficial program syntax. Alternative representations of source code. Some kind of (intuitive) graphical visualization of software would be very useful. Both for building programs and looking at programs from a new perspective. This could also include intermediates between fully graphical and fully text, or simply looking at the program in another syntax.
- literate programming: why did this never go anywhere in the mainstream? the perspective/train of thought of the developer would be another input to the person maintaining the code. Code comments are part of the solution, but they're completely separate from the program. To be more useful the there needs to be a deeper way to associate/interleave the train of thought and even discussions between developers with the code.
Anyway, there's probably lots of issues with these ideas, but I do feel that better tools of the trade could help. Things don't have to be completely automated, but the computer could certainly help more in filling in the blanks. It seems that with all the jobs 'we' automate, there is little focus in automating part of the job of a software developer (on the other hand, the state of the art does advance, high-level languages like Python and PHP already helped a lot in making us more productive, oh man imagine that we had to write everything in C...)
I'd like to buy Zack a drink, because all of this is obvious to those poor shmucks among us that handle the support end of things (also known as the "shit end"). I've been saying a lot of the same things for years. I'm tired of it now; I'm starting to give up, because it's obvious there isn't a programmer out there that gives a damn. You can try telling them that there's something wrong with software -- something fun…
Earlier quoted context omitted.
>allowed_users You can pay someone to implement this, as well as any other missing AD features, then open source it so no-one has to implement it again. The original devs that did much of the reverse-engineering work on Samba have since moved on to much more rewarding work. That work will essentially never be done again, nor be improved upon until financial incentives are introduced. Much of the work on Samba since h…
Thank you (seriously) for demonstrating the part where I said, "but they'd rather tell you why you're wrong rather than really listen to why you're frustrated." > ...as well as any other missing AD features... This isn't exactly a feature, it's a core part of AD permissions. Samba 4 was developed for the purpose of taking on server roles in an AD environment. > We are not your servants, we are people. Give value, get…
I am amazed once again at some people's ability to take free stuff and complain that it isn't making them money fast enough.
Just take a few seconds to think about the value we all get out of the deep and broad Free Software stacks. Finding bugs and fixing docs is a part of that process. You're not entitled to any of it, but you're welcome to participate and partake of the fruits.
I suggest anybody interested to read: No Silver Bullet: Essence and Accidents of Software Engineering http://news.ycombinator.com/item?id=3068513 for a better idea why the state of art is actually much less terrible than it appears to idealists. "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fide…
I'm a bit unconvinced, since specification, design, and testing could be fundamentally different and vastly improved from the way they are now, not just the area of syntax errors.
E.g. think why Google just doesn't buy Oracle servers instead of developing all their software infrastructure -- they wouldn't be able to provide the service they do and they wouldn't earn anything. Whenever you decide that you "don't care" you didn't really remove complexity, you just decided to accept the way the system behaves by default with all the limitations that come from that.
Idealists think that a lot of the details can be "abstracted away" just because they'd rather not think about them, but they are still there and they make the difference.
Anyone who liked this article may like to know that Alan Kay and his team at the Viewpoint Research Institute are currently making a silver bullet. A real one. Of the kind that really really hurts the Complexity Werewolf. They may not kill it, but the scars are already visible. Take a look at their work, most notably the last STEPS progress report. They can use 50 times less code than well written, useful C code (lik…
Other efforts similar in spirit but dramatically different in execution are Intentional Software and Jetbrains MPS. I really need to find a weekend to try to parse through VRI's work. Has anyone tried to make a digestable survey of the work they have done? I've glanced through their documentation but it seems quite sparse and their stuff is a moving target.