 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| The future of software engineering? |
|
 |
Kahsm Member since: 12/29/2003 From: Whitby, Canada |
|||
 Posted - 2/6/2006 1:42:08 PM |
||||
| Hey guys, I've been thinking recently about where software engineering is going. This started when I was learning about RAD and CASE tools. I'm wondering if you guys have any neat ideas as to where the industry is headed. I have some ideas, you can either comment on mine, or add some of your own. If anyone has any litterature on the future of SWE, I'd love to read it. 1) Rapid application development with UML. This stuff already exists in some places. Draw your UML diagrams, hit compile, and it writes the code for you. Attaching moduals would be as simple as opening up new diagrams. 2) Collective source database (pattern recognition). You know when you're using word, and you type "Dead so and so" and the paperclip pops up to say "It looks like you're writing a letter!". Well I think we may end up with something like that for programming. Your IDE would be linked to a central database for your business/affiliates. As you're coding away, if it recognizes what you're trying to do it can suggest code snippets that are already complete and tested from the global database. Designed well, we could fly through development. 3) The fantasy idea of programs that program themselves, AI anyone? Happy speculating. ------------------------------------------------------------------- Life is short so go on and live it, cause the chicks dig it. - Kahsm |
||||
|
||||
|
eelke_folmer Member since: 10/19/2005 From: Edmonton, Canada |
|||
|
Posted - 2/6/2006 2:07:40 PM |
||||
My 2 cents.Quote: Useful but only applicable in very well understood domains such as telecommunication industry. Quote: useful but again very hard to generalize e.g. only useful for trivial things and programming in general is not about trivial things otherwise this is often already available as libraries or middleware. Quote: The future of SE lies in being able to select&componse; the right components/libraries and only write glue code and business logic. For games this is no diffent only you need to provide more content such as graphics / audio but when you have that you can easily "write" stories using script. |
||||
|
||||
|
fastlane69 Member since: 3/31/2005 From: USA |
|||
|
Posted - 2/6/2006 5:36:54 PM |
||||
Quote: Which is exactly the point...as Games Development becomes a more well understood and standardized domain, this will become possible. Furthermore, I don't see this as too far on the horizon (maybe within the next 10 years?) |
||||
|
||||
|
eelke_folmer Member since: 10/19/2005 From: Edmonton, Canada |
|||
|
Posted - 2/6/2006 7:32:22 PM |
||||
Quote: The essence of games are stories. Jack does this, Jill does that. I think natural language would be a much better format for describing this then UML wouldn't you think? |
||||
|
||||
|
RDragon1 GDNet+ Member since: 2/7/2001 From: USA |
|||
 Posted - 2/6/2006 7:36:18 PM |
||||
| "It looks like you're writing an MMORPG!" |
||||
|
||||
|
fastlane69 Member since: 3/31/2005 From: USA |
|||
|
Posted - 2/6/2006 11:10:43 PM |
||||
Quote: Hardly. What is the story behind chess, poker, or go? Stories are important but hardly the "essense" of most games. Quote: Absolutely not, at least not for SE. Natural Language is only good for interpersonal communication and even then it fails most of the time. Furthermore, describing the interrelationships between even 5 objects becomes impossible with natural language but is transparent in a visual language like UML. Besides storytelling isn't SE and even in storytelling intensive media such as tv and play, other formats aside from natural language, such as the script or storyboard, are used to describe how they are going to produce their works. |
||||
|
||||
|
Kahsm Member since: 12/29/2003 From: Whitby, Canada |
|||
|
Posted - 2/6/2006 11:32:12 PM |
||||
Quote: LOL, yeah something like that. =) I know there are programs out there right now that can spit out class deffinition code from a Class. It seems quite plausable for it to interperate a collection of diagrams and interperate the link meanings. Obviously this is for simple applications with short, easily definable methods. With respect to the source database collection, I'm thinking on a much smaller level than moduals. This would replace those times when you cut and paste a 10 or 20 line design pattern for some sort, or some pattern of ifs. Obviously we're talking in the future here, so this would be independant from variable names, and possibly even types. Your IDE coudl recognize you're trying to loop through each item in an array and multiply it by 20 and write up just those few lines instantly. I think of it like how IDEs know to put the closing bracket in now, but far more intuative. As for games, I think we'll just see more and more dependance on data than on actual code. As you said, a little glue code between some common super optimized moduals, and then shitloads of data or real language scripts. ------------------------------------------------------------------- Life is short so go on and live it, cause the chicks dig it. - Kahsm |
||||
|
||||
|
Kahsm Member since: 12/29/2003 From: Whitby, Canada |
|||
|
Posted - 2/6/2006 11:40:17 PM |
||||
Quote: That's a very good point, about the relationship between multiple objects. I think companies would want to pay as few programmers as possible though, so an english based scripting languages would be where I think they are headed. Something cheaper labour could still use effectively. That does not mean however, it could not be OOPish. ------------------------------------------------------------------- Life is short so go on and live it, cause the chicks dig it. - Kahsm |
||||
|
||||
 |
ApochPiQ GDNet+ Member since: 7/17/2002 From: Atlanta, GA, United States |
|||
|
Posted - 2/7/2006 3:46:01 AM |
||||
| Games are already some of the most intensely data-driven pieces of code in the realm of computing. (There are some applications which are even more data-driven, but they tend to fall into fairly narrow problem domains.) Personally, I think the concept of "programming by UML" is dangerous, and needs to be carefully constrained to certain types of problems. The more layers of abstraction we add to a problem, the more we tend towards "UML to code converters," the more likelihood there is of something going wrong at the lower layers. Ask any Java programmer who has tried to make professional and widely accepted applications for Windows: the abstraction can very easily get in the way of certain goals. There are also performance problems. Sure, I might be able to drag my UML blob for "extract the fifth word of the input sentence string" into my code and have it work, but how optimal will it be? What if I have a routine that extracts the fourth, then the fifth word from the same sentence? What if I need to run that routine on ten million sentences? Any competent programmer will write the code to do the fourth-and-fifth word extraction in a single pass over the string; a naive, drag-and-drop-from-UML approach will iterate over the string once for the fourth word, then once again for the fifth. This is wasted time, and over ten million iterations, this can become a severe performance problem. That kind of situation is where the human mind is currently (and likely always will be) better at finding solutions than any algorithm. [Aside: if you're unsure of why I say this, have a look into phenomena like the General Halting Problem.] Programmer brains are better at writing code than computers, because computers exist in a limited, deterministic world. The Strong AI hypothesis of course suggests that we can eventually develop AI that will rival the ability of programmer brains, but that's an extremely long way off, if it's even possible at all. And even if that day comes, we'll need programmer brains for some things that AI just won't be well suited to. There are some areas, like business logic, where UML-to-code generation is appropriate and will not wreak havoc. However, in those areas, such tools are already used quite widely, so IMHO there isn't room for much in terms of revolutionary change there. Obviously tools and methods can always get better, but I don't think we're looking at any earth-shattering changes from that arena. Code libraries are a different matter. The problem with code libraries is that all code has slightly different needs; it's never possible to just copy/paste a block of code between projects and guarantee that it will work 100% without any tweaking. In the best cases, we tweak some variable or class names, and we're set; in the worst cases, all we can copy is the algorithm, and the code itself has to be totally redone. (As for auto-detecting what kind of code you're trying to write: forget it. Your prediction tool will always mispredict something, and inevitably it will end up causing more harm than good. I never want the computer to presume that it knows better than I do what I'm trying to do, and pattern-recognition systems like that simply excel at such presumption.) In that sense I think there is some potential for pre-built repositories that generate code. However, code generation requires some meta-programming; to do code generation, we have to know some things about the code itself, track data about the code itself. This means that, in order for code generation to work well for code libraries (by which I mean that your library tool can, for example, drop in a bubble sort algorithm into your code on demand) the code needs to already be fine-tuned to work with such meta-data. Actually, I think the future of programming lies in such meta-data anyways. Writing actual code is tedious and usually the least interesting part of programming. I think we'll start to see a new breed of tools that lets us manipulate code as a substance that is more than just text. I think the solution is to start thinking of code in terms of algorithms and abstractions, more than just low-level operations on "stuff." Aspect-oriented programming is sort of the right concept, but IMHO it misses some important usability traits that keep it from being really practical for generic programming. Frankly I think my thoughts on this don't make much sense, because I haven't thought about it enough yet  There's really a huge realm of potential in the meta-code realm, and I have this intuitive feeling that we can find some really incredibly powerful stuff in that realm, but I don't have any real examples of what I'm feeling. It's all sort of on the "tip of my brain" so to speak, but hasn't quite fully formed into a coherent idea yet. |
||||
|
||||
 |
Raduprv GDNet+ Member since: 10/19/2002 From: Romania (now living in USA) |
|||
|
Posted - 2/7/2006 4:08:49 AM |
||||
| How about: "There will be no significant changes for the forseable future!" ? UML & go (that is, make an UML, hit Compile) might be useful for those who are new to programming, and are trying to do some small tasks. However, I can write a C program to do a simple task much faster than you can put the UML blocks together and hit "Compile". Try to make a MMORPG that way, see how easy it is. As for the IDE predicting what you are going to write... I don't even want to think of that. I mean, how the hell would the IDE know what I have in mind? To me it seems like the SMS text prediction, I have it disabled because it is too god damn annoying. While it might work to autocomplete fors and whiles, it would be totally useless for any real life situation other than for/while. |
||||
|
||||
 |
Oluseyi Staff Member since: 5/14/2001 From: New York, NY, United States |
||||
 Posted - 2/7/2006 4:24:44 AM |
|||||
Quote: Diagrams of even mildly complex systems are hard to author, even with great tools. I used to be a proponent of this system, but I'm a lot cooler on the idea now. Quote: Dead?  Quote: Well, Code Snippets already exist in Visual Studio 2005, but the IDE isn't so presumptuous as to interject when you're writing code. Thankfully. Also, many organizations maintain large source repositories which you are expected to look through for routines before writing new code, to minimize duplication. That sort of thing is being opened up to individuals with repositories like GotCodeSnippets.NET (video). Quote: At which point, why bother with software engineering? Go outside and play, and leave it all to the machines! I don't see any significant changes in software engineering as long as we continue to write code. SE is the process of transforming abstract requirements and ideas into concrete code quickly, efficiently and with as little error as possible, managing changes to the requirements over that process. I doubt that process can be significantly altered. The real wins, IMO, come from better code and code generation technologies - better languages, better abstractions, etc. YMMV, of course. |
|||||
|
|||||
|
C0D1F1ED Member since: 12/26/2002 From: Belgium |
|||
|
Posted - 2/7/2006 5:20:12 AM |
||||
| "Software Engineering: Programming in spite of the fact that you can’t." - Edsger Dijkstra Essentially software engineering isn't going to get any easier. We just get better tools for managing bigger projects. That doesn't mean you're leaving the office any sooner of you have to use your brains less. Because if you do, there is a big chance the competition produces superiour software. Too many companies thought they could survive by producing 'adequate' software. The overwhelming abundance of tools and methodologies isn't even always helping. Just look at beginners, they hardly know what's the best for the job. When I started programming there was C and the CRT. And even though that required to reinvent the wheel a few times, at least we knew exactly what we were doing. Tools are for the good programmers, not to allow bad programmers to produce code too (cfr. Dijkstra quote). So while lots of Good Things emerged in the last few decades, I think one necessary step for progress is to get rid of the junk. One example is to ditch CVS for SubVersion, but there's tons of other examples where one tool or method supersedes a legacy tool completely... |
||||
|
||||
|
Anonymous Poster |
|||
|
Posted - 2/7/2006 5:20:50 AM |
||||
| The two directions in software engineering we are talking about are Model Driven Development and Design Driven Development. The former is about automatic code generation by tools, the latter is about writing meaningful code, that is, modelling with the aim of expressing properties of code which were hidden before. The design driven way will change our way we think about object oriented programming. It will introduce new language construct, new concepts, new patterns etc. which can express complicated things. This will get the basis of more model driven tools (the model is discovered by design driven developers) which will help constructing software in a rapid way. Model driven development is the engineers way of programming. It will bring out new business workflows. Design driven development is the scientist way of programming. It will bring new insights which can be used for tools. |
||||
|
||||
|
5MinuteGaming Member since: 7/8/2004 From: Stratford, NJ, United States |
|||
|
Posted - 2/12/2006 10:42:25 PM |
||||
| This is a most interesting discussion of the future of Software Engineering though some posts focus more on the tools and software applications available rather than the Abstraction and focus on process. First I think we'd all agree that the future of programming will be determined by new programming languages. In particular the development of higher level languages. Now as for the future of software engineering. That would be the development of more concrete methods to control the development process. In itself software engineering will only change with the different types of languages, machines, and problems that computing is all about. The future of UML diagramming may lead to an alternative to coding using a text editor. However in UML's current state it only abstracts the function of an application so that it's easier to understand. The lowest level that UML dips into is at the function level with the flow diagrams. The development in UML's respect MIGHT YET yield a change to Software Engineering but at UMLs current state I fail to see any changes that could be possible other than automatic code generation which would not change the development process nor requirements definitons or even other software engineering concerns. In my opinion any change in computer programming and related fields will most likely come from new programming languages. I believe and am in favor of a language better suited for design patterns where you can use a design pattern as you would use any basic type in imperative programming. But as for change in Software Engineering new project development models and principles as well as processes and standards are likely to emerge. That is of course all in my humble opinion. |
||||
|
||||
|
eelke_folmer Member since: 10/19/2005 From: Edmonton, Canada |
|||
|
Posted - 2/13/2006 2:52:49 PM |
||||
| I don't really think the future is in more advanced languages (look at eiffel which is more advanced than existing OO languages but has failed to gain a large following). As more and more reusable components and application frameworks become available the building blocks of building software are just getting bigger. We only need glue code to put them together and scripts for programming the business logic. You also see a lot of design patterns becoming available in components or frameworks. (See for example MVC in java struts and generic Undo in java swing). I think the languages available to a programmer will become more simple and "visual" such as UML. I'm not saying programmers need simple languages but programming business logic simply does not require that. |
||||
|
||||
|
JD Member since: 11/3/1999 From: USA |
|||
|
Posted - 2/13/2006 7:21:15 PM |
||||
| As time progresses, we'll see more and more specialized tools being produced that fill the various niches. I think when procedural langs were introduced that we pretty much got it nailed down. At the heart of any program are procedures and specific tools like OOP, etc. are just addons that improve the experience in some cases or hinder it in others. Obviously, for applications the IDEs and OS libs/frameworks are equally if not more important. That is where code reuse has been realized the most ie. the success of MFC/WxWidgets for example. |
||||
|
||||
|
Nathan Baum Member since: 4/4/2005 From: Bournemouth, United Kingdom |
||||||
|
Posted - 2/13/2006 8:46:56 PM |
|||||||
| The Silver Rule: There is no silver bullet. The future of software engineering will be the seamless integration of domain-specific tools in which programs can be expressed with as little redundancy, irrelevency or possibility of error as possible. Hence .NET, and to an ever greater extent, Comega. Of course, Lisp has been doing this for decades. Quote: FUD Because a UML compiler could be inefficient, a UML compiler must be inefficient? People used to say the same about source compilers. I'm not convinced. There are good reasons for not using UML as a "programming language", and good reasons why even if you did, it wouldn't result in a quantum leap in software engineering, but performance is not one of them. Quote: Of course there are a great many things that humans are better at than computers, but the Halting Problem is not one of them. Nothing can solve the Halting Problem. Quote: I haven't used any code predicting systems. Can you provide citations of studies in this field which support your conclusion? Quote: Sounds like macros. Quote: Sounds like higher order functions and types. Quote: Sounds like Lisp. |
|||||||
|
|||||||
|
ApochPiQ GDNet+ Member since: 7/17/2002 From: Atlanta, GA, United States |
|||
|
Posted - 2/13/2006 11:03:50 PM |
||||
| UML Generation The performance problems are not insurmountable, but they do pose a huge obstacle. The domain space of optimizing a high-level UML-type design is an order higher than optimizing instructional code like C; considerations for performance (both in space and time) cannot be made merely at the algorithmic level, but also at the meta-algorithmic level (e.g. detecting the nested-search case I provided earlier, which frankly is one of the most trivial cases there is). In order for UML-generated code to be performant enough to become widely used across many problem domains, it will have to overcome those optimization problems, or the concept will remain unpalatable to anyone who understand code optimization. The problems are not insurmountable, but they are not merely trivial. Many experts would argue (quite correctly) that optimizing compilers took decades to reach a level where they could routinely compete with - and beat - hand-tuned assembler code. IMHO we'd be looking at a similar time-scale for solving optimization problems in a UML-compiler system, albeit with a lot more market inertia to fight against. I doubt we will see a domain-generic UML-generated code platform become prevalent, let alone dominant, within the next decade. The Halting Problem The only counterexample to human solution of the General Halting Problem (that I am aware of) requires highly massive and intricate programs. The idea here is that the human mind cannot solely track enough state to recall what the program is doing, and thereby cannot reliably solve the General Halting Problem. Paradoxes and cheats like "find the largest prime number" do not, IMHO, count. In any case, human beings are capable of easily solving the Halting Problem for specific cases that take massive amounts of effort to solve mechanically, which means that at least for now we're going to be a lot more efficient at choosing designs and algorithms than a machine. That might change, someday. But I highly doubt it. By the time we become collectively smart enough to write auto-generating code systems that can solve today's problems, we'll have moved on to a more difficult problem space. It is exceedingly unlikely that computers will ever exceed the concurrent ability of the human mind to design and implement good systems. Code Prediction I didn't speak of scientific evidence. I would have hoped it was clear that I was making an opinion statement (note the phrase "I never want..."). That will never change, for me personally. I never want a machine to presume it knows better than I do what I'm trying to do. Hell, I don't like it when people do it, and people are (for the foreseeable future) much better at predicting human behaviors than any currently developed computer system. Lisp Just wanted to say I think it's funny every time a Lisp-junkie mentions the No Silver Bullet rule More on topic: I'm aware of Lisp and all of its endless, glorious greatness. I forget who said it here, but a while ago someone made the quip to the effect of "I don't want to learn Lisp, lest I become an annoying Lisp zealot." Not to assault Lisp, or make any particular (likely unfounded) generalization about Lisp users, mind you. Here's my question: if Lisp is The Silver Bullet (oh come on, you know you think so  ) then why hasn't Lisp developed the Next Killer App? Why is Lisp not responsible for massive feats of modern software engineering, if it is truly capable of so much better programming paradigms than, say, C++? The only really noteworthy thing I know of that used Lisp on a serious, killer-app scale was the Yahoo Stores application, and from what I've heard that's been rewritten long since. [NB: Lisp as an embedded scripting language doesn't count.]My personal opinion: Lisp has great concepts, but the execution is painfully weak. Merge a clear, easy-on-the-eyes syntax (think VB, Python, maybe C#) and a hugely rich library of prefab code (think C, C++, any .Net language, PHP...) and then throw in the powerful features, and you might have a winner. I have a little trick for determining the domination-power of a language (for the desktop, fat-client domain): measure how long it takes to get a graphical, animated Hello World built. .Net languages make this so trivial it's actually funny - and they will continue to consume more and more market share over time, because they are both accessible and rich. On the flip side, I've never even heard of DirectX bindings for Lisp. Lisp is rich in philosophy, but not accessible, and not rich in support for Stuff We Really Need. To make it simple: I think the future of programming language tools lies in recognizing the power of the techniques that languages like Lisp give us access to, and combining that with the tremendous accessibility and base support of current technologies. Make a Lisp that reads like Basic and has trivial C-API binding capabilities, and you might get somewhere. |
||||
|
||||
|
JD Member since: 11/3/1999 From: USA |
|||
|
Posted - 2/14/2006 3:03:23 AM |
||||
| Many of the programs made in Lisp are not commercialy based so it's harder to know about them. They're probably used in academic circles or expert systems in financial district. App dev is more mainstream and thus the langs. need to be tied to the gui infrastracture to be useful there. Historically C and C++ were such langs. C because it was tied to unix and system dev and C++ to MFC. Maybe .net + Lisp is possible but how it turns out I don't know. I think that syntax is one part in the decision to use a lang, at least for me the other is all the infrastructure I need for both gui and non-gui app dev. I always related Lisp to AI dev and maybe it's preceived niche had a negative impact on its possible mainstream use. In any case I'm a game dev and so far I've not had the need to use Lisp nor anything outside the procedural/OO norm. I think Lisp is nice to have but not a must have lang. A must have lang. would be one you couldn't do without and most game devs do fine with C/C++ at least for now. |
||||
|
||||
|
Nathan Baum Member since: 4/4/2005 From: Bournemouth, United Kingdom |
||||||||||||
|
Posted - 2/14/2006 7:18:34 PM |
|||||||||||||
Quote: My observation is simply that performance isn't that big a deal, compared to other criteria in selecting a programming language, for most software development tasks. Even in games development, which is often held up as an exception to this rule, the popularity of scripting languages shows that many games developers are more than happy to sacrifice performance for safety and maintainability. Even then, this sacrifice is usually not a problem. It is well known that programs don't spend equal time in every part of the code. Only hotspots really need to be optimised. Parts of the code executed only infrequently are unlikely to result in an observable improvement in performance, which is what matters in games. Now, I've said that performance is generally secondary to safety and maintainability. I think the past supports this conclusion. When compilers were first introduced, some people who wanted fast code refused to use compilers because they believed (at first rightly) that compilers produced slower code than humans. Whilst compilers now routinely produce better code than most programmers could generate, they won before they got to that state; they won when people realised that the advantages of using compilers far outweighed the disadvantages, in most cases. So does this mean UML is the future of software engineering? Well, certainly, the human designers of these hypothetical UML compilers will eventually make them produce code as performant as compilers for conventional character-stream languages. But as I've been saying, performance isn't really that big a deal. The case for UML's strength in making software more reliable, secure and maintainable has not yet been made sufficiently convincing for my liking. Quote: No. It isn't a question of reliability. Humans cannot solve the general halting problem, because the general halting problem is unsolvable, even in principle. Quote: A solution to the general halting problem is a paradox. Quote: On what do you base this assertion? Quote: It appeared quite clear that you were saying that the reason that you didn't want a computer to do 'code prediction' was that it couldn't ever predict correctly. Quote: People used to say the same about compilers. Many of those people are now using compilers. Quote: Why would that be funnier than, say, an OOP-junkie mentioning it? Quote: It certainly sounds like you're making a generalization about Lisp users. Quote: If I thought Lisp was the silver bullet, would I have left myself open for attack by opening my post with the assertion that there was no silver bullet? Only if I'm a complete idiot. Do you think I'm a complete idiot? Quote: [NB: Why not?] Quote: I disagree about the syntax, but yes the lack of well-tested well-documented library code is a significant issue. Quote: This took me about an hour from scratch in SBCL. (require :sdl) (require :sdl-ttf) (sdl-ttf:init) (defun draw-text (surface font string x y color) (cl-sdl-ttf:with-solid-text (s font "Hello, world" color color color) (cl-sdl:clear-screen surface) (sgum:with-foreign-objects ((rect sdl:rect)) (sdl:fill-rect surface rect 0) (setf (sdl:rect-x rect) x (sdl:rect-y rect) y) (sdl:blit-surface s sgum:+null-pointer+ surface rect) (sdl:update-rect surface (sdl:rect-x rect) (sdl:rect-y rect) (sdl:rect-w rect) (sdl:rect-h rect))))) (let ((surface (sdl:set-video-mode 640 480 32 (logior sdl:+hwsurface+ sdl:+doublebuf+))) (font (sdl-ttf:open-font "Vera.ttf" 12)) (fullscreen-p nil) (x (/ 640 2)) (y (/ 480 2))) (unwind-protect (sdl:event-loop (:idle () (incf x (- 1 (random 3))) (incf y (- 1 (random 3))) (draw-text surface font "Hello, world" x y 255)) (:key-down (scan-code key mod unicode) (case (code-char key) (#\q (return)) (#\f (sdl:show-cursor (if fullscreen-p 1 0)) (setf fullscreen-p (not fullscreen-p)) (sdl:wm-toggle-full-screen surface))))) (when fullscreen-p (sdl:show-cursor 1) (sdl:wm-toggle-full-screen surface)))) (quit) Of course, this is a pretty stupid technique for determining "domination power". If I were in the habit of making animated hello-world programs, I'd have a ready-made library of functions and macros which would have enabled me to write the thing in minutes: (with-surface (surface :width 640 :height 480 :bpp 32) (let ((font (load-font "Vera")) (x (/ 640 2)) (y (/ 480 2))) (event-loop (standard-demo-event-loop) (:idle (ticks) (draw-text surface "Hello, world" :font font :x (incf x (rand -1 0 1)) :y (incf y (rand -1 0 1))))))) So what does this prove? Well, not much. A C++ programmer who was in the habit of making animated hello-world programs would probably be able to subclass some demo class he made and replicate my effort in not much more time. Really what it shows is that some languages are more adept at doing GUI stuff "out of the box" than others. Is that enough to translate into "domination power"? I don't think so. What makes a language powerful is the ability of its programmers to produce high-level abstractions which they can use again in later projects. Code reuse is essentially the closest thing we have to a silver bullet (it is perhaps an iron bullet (iron is also considered to be harmful to supernatural creatures in some folklores)), but really it's ducking the issue: because software engineering is hard, and is likely to remain so, code reuse says the way to solve the problem is simply engineering less software. Most languages support code reuse via abstraction of functions and types, but Lisp supports a metalinguistic abstraction which makes it easy to reuse patterns. In conventional programming languages, pattern code is reused either by copy-pasting and then amending what's there, or by using IDE wizards. There is, lately, a delightful focus upon integration of different domain-specific languages which can do in one line what would take hundreds in a general-purpose language (vanilla Lisp being no exception). From antiquity we have SQL, and now we have languages like XPath and XSLT. In games we also have scripting languages like Lua, the sublime UnrealScript (which knows about client-server replication, prediction, authority roles and threading without needing the programmer to jump through hoops) and even id have a language of sorts for the abstract high-level description of texture shaders. (A particular advantage of this over using a more concrete fragment shader program is that systems without fragment shaders can still use the texture, and it also becomes much easier to edit the shader with a GUI texture designer.) This kind of high-level reuse is the way to go. It really began in the 1950s when mediocre programmers started to reuse the work of highly skilled programmers via the use of compilers. Now users of SQL, UnrealScript, XSLT, etc reuse the work of highly skilled programmers without themselves needing to be experts in searching databases, distributed computing or graph transformation. This all links back to UML in a funny kind of way. Whilst using UML as a general-purpose programming language is a Really Bad Idea, it's a really good idea to use graphical programming systems in certain contexts. Two examples that I've used spring to mind immediately: 3DS Max's particle view, and the aRts builder. The particle view enables one to construct a controller for a particle system by, essentially, visually constructing a finite state machine. The aRts builder constructs an audio effects program by piping audio inputs through a variety of audio filters into audio outputs.   It seems like the particular merit of these system is that (1) they're very high-level, (2) the entire diagram fits on a few screens and (3) they describe things that don't have a simple tree-like structure. To represent them in a text-based language would mean using variable names to denote each node and then you'd have to hope that you linked each node to the right node. In the graphical view, it's easy to see what each node is connected to. |
|||||||||||||
|
|||||||||||||
|
Nathan Baum Member since: 4/4/2005 From: Bournemouth, United Kingdom |
|||
|
Posted - 2/14/2006 7:58:22 PM |
||||
Quote: Perhaps what you really mean here is that not many programs written in Lisp have commercially available source. That's the most that can be inferred from the apparent lack of mainstream Lisp development: if the source is not made available, you really don't know. I daresay a lot more software is written in Pascal, COBOL or FORTRAN than you'd expect: you don't hear about it because the source isn't made available. Quote: It's highly possible. Microsoft even included a Lisp system in a previous incarnation of the .NET SDK, although they didn't advertise it widely. I don't know if it's in current versions, but you might be able to find it in "Tool Developers Guide\Samples\clisp" in the SDK (that's if you have the SDK, of course). |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
Page generated on 2/15/2006 in 0.3604 seconds.
