Re: Software Development Has Stalled
Posted: Feb 11, 2010 12:48 PM
In no particular order. These threads are why I love this site :-)
> > Writing iPhone apps is a different problem from
> > defining and managing data for a commercial enterprise,
> > which is completely different from the problem of
> > the development of weather or weapons simulations. And
> > on.
> Not really. The similarities between those are way more
> than you think. I am confident about this, since I have
> been involved in military applications for the last
> decade, and in iPhone development the last six months,
> with the occasional mix of commercial enterprise apps
> thrown in from time to time.
Yeah, but it is the differences that can kill you. If you've done them all, I'm sure you've worked with people that were somewhere between mediocre and good with enterprise apps that would cry if they had to follow the rigor of something that was shipping for the military. Likewise I've known people that worked on military grade stuff that couldn't handle the pace and flexibility needed to do enterprise stuff. Some folks just aren't wired that way.
>> Frankly, I think this industry would be far better off
>> without people who continue to push the magical thinking
>> that a tool or language or framework will somehow solve
>> all the problems of software development.
> Thank you for the reply. For the record, I agree with
I agree completely, but we can come up with tools and frameworks that make our lives easier. I just don't want that to get lost in the shuffle. I'm guilty of throwing the baby out with the bathwater on that one from time to time.
> I have some ideas that combine the performance of C++,
> the flexibility of LISP and the parallelism of Erlang. We
> can open a discussion about this, if anyone is
Definitely interested. I'd be interested to see how your thoughts compare with what D has already done. While D certainly isn't as flexible as LISP, it was originally put together as a better C++ (it performs almost as well in most situations from the benchmarks I've seen and it keeps the one thing I love about C++ which is at best an afterthought in almost every other language and framework out there, and that is deterministic destruction) and it has some pretty solid primitives for parallel programming that take care of most of the issues with threads.
>My opinion is that we can have big new advances if we go
>back to some concepts that were abandoned but seem to
So you're saying innovation isn't all it's cracked up to be? Because this is much more in line with my view/definition of innovation that I originally put forth, which you beat up. Revisiting existing, abandoned concepts is about as far from 'new' as you can get.
>One of these concepts, in my opinion, is the uniform
>representation of data. The concept of uniform
>representation originated in LISP. I do not propose to go
>back to actual LISP, but to revisit some of the concepts
>of LISP, perhaps in new way to implement them.
>Regarding the decoupling of data and code, I do mean to
>abandon encapsulation. I mean to decouple information from
>programs. Right now, information is not readily available
>for anyone to manage. One has to go through a particular
>application to manage the information. This is very
>different from encapsulation, which I do not think it
>should be abandoned.
At some point data needs context. badbread can be a string, a hex representation of an integer or a memory address, depending on the context and what level you are comfortable working at. I can understand why you want to do away with that sort of thing, but in some cases, it is important to know things like register addresses and memory locations. After all, somebody has to write all these interpreters and compilers and programming tools. In the average case you don't need, or even want, to know about these things, but when you need them, you need them.
The program still has to run and do something. Sometimes how fast and how much information it can process is part of the requirement and we don't have enough spare cycles available yet where you can just make the need to know this stuff disappear. We're getting there, slowly, but we're not there yet. I'll be surprised if we are there in my lifetime. Sure we should work toward the theoretical goal, but every year I get a little more saddened by how many people have absolutely no understanding of what they are doing when they type stuff into a text editor. It almost physically pains me when somebody hits a wall and they have no idea where to even begin to work around it. They just did what the manual/book/tutorial said and suddenly it doesn't work and I don't know why and can you please please please fix it.
Having a big pile of stuff without any structure or context is good in some cases and bad in others. If I am a herpatologist who specializes in studying constrictors and google for 'python', I'll find the results to be useless. Information, like sound, without structure and context is just noise.