I'm writing a very simple Java Game. Let me describe it briefly:
There are 4 players in a Map.
The map is a two-dimensional matrix with a value called "height"
The height between 2 nodes is the cost of that edge.
Use Dijkstra algorithm to help player navigate from a source to a destination.
Four players take turn to make a move. The total move is 8( left top, top, right top.... )
If they meets, fight for gold value, otherwise move to their target.
As they move, their strength decrease by the height difference between two nodes.
... etc
....
The problem that I'm encountering is that the source code is getting longer and complex day by day. And I think I'm using a wrong approach somehow, I feel so tired because of constantly changing the implementation. Here is my approach:
Write out all requirements.
Create all the object that I need with all getter and setter.
Create a static class to test the logic
Create unit test while putting the logic together
Add some more code, then change to code to fit the test
Write a big method that run, then break it down into smaller methods, then write unit test again.
If everything work fine, add more requirements, add more code
Then things are getting complicated because the more code I added, the complexity increases. No longer have time to write unit test because create a test case now requires too much work
Re-design, then change the implementation, go to step 1 again.
I'm come from a C++ background, and I'm only comfortable with writing 'static' libraries such as: stack, queue, link-listed, tree... Game is really a big challenging to me, especially I have to use Java. I understand the core programming is the same, so picking up Java was not really that bad. However, the time of looking up Java's API is not little. Further, the game logic is really hard to write. When this object moves, other object got affected..., so creating test for a method depends on many other methods...etc.
I really need an advice. Could anyone share some experience of how to write a game to me? I only have two weeks left for this assignment. I'm currently have 45 classes now, I feel so lost because the more I wrote the more it gets complex :( !
Best regards,
Chan Nguyen
First start thinking like a java programmer. Think as every thing in your game as an object, like the board, think about the properties and methods it has, its interfaces, how it interacts with the other objects.
If you need help getting started here is a great tutorial that guides you step by step to do a simple java game, this might put you in the right frame of mind to start programming your own. I strongly recommend you to follow the tutorial.http://www.cokeandcode.com/asteroidstutorial and to use the libraries that they used for developing the interfaz there.
I view game code architects with respect: games are complex systems with emergent properties at runtime, unusually intense interaction requirements (UI, controls) which makes a lot of OOP theory questionable value. It can be difficult to reuse game code. And, a lot of upfront planning work is wasted time.
Most game coders I know, beginning or veteran, succeed with a "just do it" iterative process. e.g.
1) write a minimal prototype. get a very basic system working, using the simplest, most obvious architecture you can think of. (my guy can run around the screen). 5 or 10 objects max.
2) add functionality (points, rules, traps, NPC behaviours, etc) and playtest, over and over. This hack on hack can makes for poorly structured code, but most coders can make it work.
3) rewrite. Programmers grit their teeth at some of the hacking they had to do in (2), and will want to throw it all out and rewrite. Resist this urge until the game is testable (as in, plyaers can sometimes enjoy it, somewhat), or a new feature would require rewriting. Then, rewrite pretty much EVERYTHING from scratch. This goes WAY faster than you'd expect, and results in solid, well-structured code.
Game coders do test, but comprehensive testing of ALL code is rare. two reasons: emergence and culture. Games have emergent properties at runtime ("yeah, but the points COULD go negative when the NPC is killed when ...."). Since games are usually for entertainment purposes, there is a culture of fast-and-loose testing. Games aren't as important as, say, missile control code.
I expect others with more coding experience answer this. (I have written a fair bit of code but I tend toward quick and dirty script type coding style - I know lots of coders who are way better than me.)
I have been struggling with an idea for a few weeks and wanted to see if someone can help me out here.
Programming today is full of abstractions, and people who do not understand the abstractions, do not truly understand the reason or design than went into building that abstraction/layer/framework and will struggle as soon as they step outside the comfort zone.
I was wondering if there is a learning resource that goes about teaching programming in an incremental fashion. This will lead to understanding the full stack.
take a small problem
implement a simple solution
talk about the the solution and the designs used
convert the solution into a framework or utility of some sort
now extend the problem space and repeat from step 2.
This way when someone then picks up any framework/library, they can easily visualize the problems the framework is trying to solve, the design decisions taken and the reasons thereof.
[Added to clarify the intent]
Based on the answers and comments below, I want to clarify that I want to move further up the stack. Building your own ORM to understand ORM better, same goes for ActiveRecord, IOC container, data binding, templating engine, and the host of other magic/glue/plumbing we use day-to-day.
Thanks.
Here's what I recommend : Have a brush with assembly (just one book or one month is enough). Have a good strong review of C++ (hopefully it will teach you some of C as well). Now the world is yours. Python is made in C/C++ , Object C is pretty close to c++, .NET is in C++ and C#/VB.NET , The windows API is oriented for C.
I picked C# as my abstract language of choice after this by the way.
Read the source. It is a good idea to build something you want to understand, but you can enhance your understanding of concepts significantly by looking at how something is built. This is especially true for infrastructure pieces (ORM/DI/Templating) which you seem to be interested in.
Get the software to build on your machine, attach a debugger and trace through the code. This is pretty easy for C#/Java with a good IDE. For dynamic languages like Python and Ruby, it takes a good editor and a lot of grepping.
If it is a good software package, it will usually have tests. Tests are a great place to start digging into code. They usually make clear the intent of the code, and also provide you a logical starting point to peel off the layers and actually peek under the hood.
Build a fully functional compiler from scratch in a systems language like C or C++. Maybe it isn't the full stack, but it's a large part of it. This is something I want to do as well. If only I could find the time and space.
The best example of the sort of learning resources I am seeking is the MIX session by Rob Eisenberg on "BUILD YOUR OWN MVVM FRAMEWORK". It goes step by step on explaining the pattern and also implementing it at the same time, attacking one problem area at a time.
http://live.visitmix.com/MIX10/Sessions/EX15
Hope there are more out there.
I learnt swing basics and event handling basics from head first java...
Then i read a few tutorials on swing app development using netbeans...
and i loved it as i don't have to care about layouts and stuff...
But i read in one of the forums, that i should learn swings properly rather than using netbeans directly...
This confused me a bit....
Please suggest the best way to master development of swing apps....
thanks in advance
Well, I see I'm going to run counter to the majority here ;-)
Hand coding GUIs is a pain in the ass. Anything that makes that task easier is a good thing in my book. When you're just starting, having a generated GUI lets you get up and running faster.
GUI builders handle the really repetitive work and prevent you from doing the most common dumb things. The downside is that same approach will also prevent you from doing the really clever things. Eventually, you will encounter something that you cannot do through the GUI builder and you will need to poke into the code. So, you can't treat code generators like black boxes where you don't need to know what magic happens inside. At minimum, you need white boxes. Let the GUI builder do its magic, but understand that magic and its limitations.
Practice by generating a very simple GUI. Walk through the code and understand what it does. Make a change through the builder and see how the generated code changes. Try changing the code yourself to confirm you understanding is correct. *
If you don't understand something, hit the JavaDocs, the Swing Trail, or browse through the Java2S Swing Tutorials.
If you're still stuck try the kind folks at Java Ranch, or here on StackOverflow.
* Netbeans puts the generated code in guarded blocks and will not let you edit them directly. However, you can open the file in another editor to test a change. Also, you can do quite a lot to influence the code generation using the code tab in the properties window.
It depends on what you see as your goal.
There is no "perfect" approach to get comfortable using Java and swing, it always depends on what you want the outcome to be like.
Most enterprises depend on stability and speed, programmers need to write code fast and stable. If you write complex interfaces by hand it gets ugly when it comes to speed and precision at the same time. You can never write better code in terms of "it is working" then the netbeans gui builder can. Also, no one will probably have a look at your code once the application is up and running.
If you want to get to know swing only for the purpose of knowing it with no deeper intention what so ever, I'd recommend learning it by heart without netbeans as you'll probably familiarize yourself with most of it's functionality quicker then the other way around.
On one hand, if I want to learn something, I want to learn it from scratch, so I would probably go with writing swing-code myself and in the end using netbeans to generate it when I am fully able to comprehend what is generated.
On the other hand, if I need to write applications quick and am not paid to go into any details, I'd simply use netbeans.
I think you have answered yourself... you want to master development of swing apps...
everything that you do by autogenerating without knowing why or how is not mastering in my opinion ;)
If you want to be master, then you should at least know how to do it with your bare hands. Moreover, it will also help you if you will use other gui toolkits (main principles of gui toolkits are more or less the same, imho).
This Question about how do i learn from basic As3 to advanced as3 , as i want to become professional in as3.And work as freelancer.
can anybody guide me how to reach to the peak of Action-Script-3.
This question seems to be really funny to many but this is the most basic question in my mind
1) which way to go.
2) what steps i should follow.
3) how should i do my first project professionally.
4) how do i become excellent in as3
I believe actionscript 3.0 and Flash in general allows you work on a wide variety of projects:
from interactive rich media web interfaces, to interactive video, animation, games, desktop applications, rich internet applications, physical installations, creative and abstract pieces, etc.
It's up to you what you want to do, but I'm guessing if you start with something that motivates you, something that you enjoy working on and learning, it's a sure way forward
and it will make the boring bits more fun, and that's what it should be about: FUN!
It doesn't matter if it's actionscript or something else you want to learn, enjoy learning/challenging yourself and you'll get there faster than you think.
Answer 1.):
With regards to actionscript, based on what you want to do with it, there are a couple of good starts. Let's say you're interested in just the code, not planning to use the Flash IDE much or at all, and your aim to develop great applications. as #David Morrow said, Colin Moock's Essential Actionscript 3.0 is great. Also his guide From the Ground Up is a compressed version of the book.
An easier lecture, but packed with hands-on tips to getting things done in actionscript 3.0 is Rich Shupe's Learning Actionscript 3.0, also from O'Reilly. This might help you get up to speed with project you might have in mind.
Answer 2.) and 3.):
In short you have at least two routes:
easy/practical start where you learn
by doing small mini projects, but
keep in mind there are gaps to fill
in order to move on to complex
projects
a 'harder'/more theory based start,
that will cover advanced topics, so
you will ready to take most projects
out there, simple or complex.
Answer 4.):
It also important to keep in mind that there is no substitute for experience! Learn how ever it feels comfortable, but plan time for practicing/writing a lot of code/failing/fixing/repeating. Don't worry about getting things wrong! I don't know any programmer that can write a complex project perfectly from start to finish. Basically all projects out there are the result of this loops of failing/fixing/learning/ if you want to put it this way.
Never be afraid of getting things wrong ! You learn more this way, than getting things right, but not fully understanding why, also, you can discover something new. You can't run
into happy accidents if you don't have accidents at all.
As you progress you will like some things more than others. It is important to try everything when you learn. Knowing what you don't like is just as important as knowing what you like. Don't take everything for granted and form your opinions while learning.
You mentioned peaks. It's great to aim high. As I mentioned earlier, actionscript can be used for so many things, that it's hard to be the best in all areas. Andre Michelle and Joa Ebert for example are very talented developers and have a lot of experience with sound. Chris Georgenes on the other hand is a very talented animator. I wouldn't expect roles to swap anytime soon. If it helps, choose people that are actionscript virtuosos, get inspired by their works, there are plenty of them out there.
HTH,
George
understand OOP classes and packages.
Inheritance and polymorphism
keep all content in external xml files
dont ever put any code in your fla
start building a library of reusable classes for common tasks ( a util library )
start working with the Essential Actionscript 3.0 and you are on your way...
read and understand this entire book and you will be rolling
The simplest, yet probably most important answer is: Use it.
The only way you'll become advanced in AS3 (or any language) is to just start using it. Do some experiments, maybe create some small tools for yourself, or find an open source app and start contributing to it.
Books will help, but they're no substitute for actual experience using the language.
As they say, you need to learn to crawl before you can walk.
You need a solid understanding of programming. See David Morrow's answer for things you should know. Also add to the list a knowledge of datastructures.
Start programming. As George Profenza said, start with a simple project first and something that you will enjoy doing. If you undertake something too big you may end up disillusioned. The best thing about working on little things often is that you will encounter certain problems, and you will learn through experience on how to tackle them.
Once you have the basic hang of things start looking at other people's source code. Visit blogs of various well known flash developers and go through their code. Learn from the best. My blogrole is a list of such people.
After a while, maybe a year or so you will be a decent AS3 programmer. Remember AS3 is just a tool. What seperates the men from the boys is being able to solve problems. Start tackling more complex problems, for example, develop a voxel engine or something along those lines. The best programmers tend to experiment with problems in the field of computer science. In doing so, they become knowledgable on various things like 3D rendering, Audio etc and develop unique skills placing them on the cutting edge.
Well I'm a visual programmer, i only learn as a means to an end - I want to make things.
If you are as i am - then here's what I recommend to go from basic AS3 to advanced AS3.
Make a game. OR, and this might be an even better route.
Clone a game that you like - e.g. tetris, bomberman, pacman
I know it a single statement answer.... not fancy, but - you will HAVE to learn so much in the process of creating it.
While thinking about software-engineering in general I came across the question why we don't see any improvements in the way we write/document code.
Think about it: There has not been a revolutionary improvement since we've moved from punch cards to text editing. The last improvement I've seen is syntax highlighting and context sensitive help (e.g. Intellisense or ctags). Not something I would call revolutionary.
That makes me wonder: Why is it so?
I'll start with something I miss badly:
Lots of my code deals with geometry.
For documentation describing geometric relationships always ends up in a big heap of hard to read mathematical stuff (due to the lack of proper equation type-setting in ASCII). However, if I could embed a little drawing or scribble into the code everything would be much easier, neater and better to be understood.
What can you think up that would make your coding/text editing/documention tasks easier?
I'm surprised that nobody has yet mentioned No Silver Bullet. In 1986 (!), Frederick Brooks predicted that:
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity. [...] We cannot expect ever to see two-fold gains every two years."
And in 23 years, he's been proven right. We've come up with a number of things such as syntax highlighting and Intellisense which have improved productivity significantly, but certainly not by an order of magnitude. As time marches on, we'll continue to make several incremental improvements, but the fact is there is no silver bullet: there's not going to be some magical revelation in the way we write code that will improve productivity by an order of magnitude.
I'm suprised that no one seems to have mentioned Donald Knuth's seminal Literate Programming - write your code as if it were a book or a scientific paper.
There has not been a revolutionary improvement since we've moved from punch cards to text editing
Never used a line editor, have you?
But seriously, text (especially in the representations chosen for modern languages) is
easily processed
fairly easy to specify
information dense
precise
Anything that comes along to replace it has to be a net win across all four of those properties. Not easy.
I disagree. We do have changes, small, but changes.
How common is the "for each" construct? Compare it to 20 years ago. How about the Domain Specific Languages movement? What about the idea that we should code in layers? How about Behavior Driven Development? Coding by complying to a specification... which writes a nice document as output when all runs fine. How about the standarization of regular expressions? PCRE. What about Alan Kay's group's DSL related work on "Moore's Law for Software", which explored a more advanced implementation of Cairo and generated TCP/IP code using diagrams from RFCs?
Documentation is a two way dialog. Both as code being more understandable and people learning this special language. You wouldn't say that German needs documentation if you know German. I know natural languages are very far away from computer languages, but there's a movement to make code more expressive. It's not about the new tools, it's about how we are coding.
One thing I've done recently in some of the more math-heavy sections of my application is to include the LaTeX markup for the particular equation as a comment/docstring. Right now, I just copy-paste into an online equation editor, but it would be very helpful to see the formula itself (with things like Greek letters and sub/superscripts) rather than a bunch of ASCII code.
Source Code In Database. In a nutshell, source code is parsed and put into a database. You'd then need an integrated IDE to view and edit the code, but at this point, syntax is decoupled from format. YOUR IDE could show you a program in a way that's completely different from someone else's, tuned to the task you're working on. I'd list some specific examples, but that article covers pretty much everything.
I'm surprised nobody mentioned it - javadoc is basically HTML, so there's nothing preventing you from embedding images (or anything else) in code. Simple, effective and ubiquitous, it's one of the things Java did right.
DrScheme let's you do these things. Here's the things you can insert from the PLT website:
http://docs.plt-scheme.org/drscheme/Menus.html#(part._.Insert)
3.1.6 Insert
Insert Comment Box : Inserts a box that is ignored by DrScheme; use it to write comments for people who read your program.
Insert Image... : Opens a find-file dialog for selecting an image file in GIF, BMP, XBM, XPM, PNG, or JPG format. The image is treated as a value.
Insert Fraction... : Opens a dialog for a mixed-notation fraction, and inserts the given fraction into the current editor.
Insert Large Letters... : Opens a dialog for a line of text, and inserts a large version of the text (using semicolons and spaces).
Insert λ : Inserts the symbol λ (as a Unicode character) into the program. The λ symbol is normally bound the same as lambda.
Insert Java Comment Box : Inserts a box that is ignored by DrScheme. Unlike the Insert Comment Box menu item, this is designed for the ProfessorJ language levels. See ProfessorJ.
Insert Java Interactions Box : Inserts a box that will allows Java expressions and statements within Scheme programs. The result of the box is a Scheme value corresponding to the result(s) of the Java expressions. At this time, Scheme values cannot enter the box. The box will accept one Java statement or expression per line.
Insert XML Box : Inserts an XML; see XML Boxes and Scheme Boxes for more information.
Insert Scheme Box : Inserts a box to contain Scheme code, typically used inside an XML box; see XML Boxes and Scheme Boxes.
Insert Scheme Splice Box : Inserts a box to contain Scheme code, typically used inside an XML box; see also XML Boxes and Scheme Boxes.
Insert Pict Box : Creates a box for generating a Slideshow picture. Inside the pict box, insert and arrange Scheme boxes that produce picture values.
You also insert your unit tests with the code that you're testing. Pretty neat stuff.
I think integrated IDEs with semantic highlighting and **semantically-constrained suggestions* (a la IDEA or Eclipse) are a huge advancement.
But that happened 8-10 years ago.
Template-based programming feels useful never seems to catch on. Recently I was impressed with a demo of the Meta-programming system, which leverages the interactive nature of the IDE to simplify the task of writing templates and what are (essentially) type-aware macros.
Meta-programming might help you define geometry-based macros that would substitute for a number of lines of code. I could imagine something that let you embed a more-readable 'math language' inside Java, and then parses its contents into something machine-readable.
I'd say version control was a pretty huge leap in how we work. The ability to keep a full record of every change anyone has made to the codebase, and to revert changes where necessary, has made a big difference.
I certainly respect Fred Brooks' argument No Silver Bullet, but I think the way we write code is nowhere near optimal, so there is lots more room for improvement. I tried to explain this in my book.
We're all familiar with "code golf", where you compete relentlessly to minimize something. That is a good way to approach the minimum possible value of that something.
What's great about this is that you are allowed, even encouraged, to break from traditions, prior conceptions, accepted wisdom, in the quest for winning. In short, you learn new things.
If the measure to be minimized is wall-clock execution time, you can do aggressive optimization.
If the measure is source code size (lines or characters) you get "code golf".
The measure I like best is "edit count". That is, given a code base, suppose a new requirement comes along. That requirement is implemented, completely, by editing the code base. Then a "diff" is done from old to new code base. The number of differences found is the edit count. Averaged over the set of likely new functional requirements, that is the measure to minimize.
If this is done aggressively, being free to contradict all conventional wisdom, the code base approaches a state I would call a domain-specific language (DSL). In this language, concepts expressed in code are in nearly 1-1 correspondence with problem-oriented concepts. In this state, it is not easy for the source code to be self-inconsistent (i.e. have bugs) because the fewer edits that have to be made to the source code, the fewer chances there are to make a mistake. It's also the case that such code tends to be short. But unlike "code golf" it tends to be very clear, because it maps the problem concepts so clearly.
So, tools and techniques that help in minimizing edit count can, in my opinion, be considered "silver bullets". DSL is one such. Code generation is another. My favorite optimization technique is another. For coding dynamically changing UIs there is differential execution. There are bound to be more, waiting to be discovered. Of course, everything depends on the training and experience of the "marksman" (the coder).
I think there are lots of new ideas to be discovered. The trick is to tell the difference between the ones that move us forward, versus the ones that hold us back.
I think this is where Doxygen and other documentation systems help. If we can embed small, discrete comments that link to other information such as:
/* help: fooimg.png */
And then have an external documentation system do that, then great.
Even better would be allowing our text-editor to treat those things as hyperlinks to external documentation.
I would reference a drawing as a reference in the code documentation. I see no reason why you can't have footnotes in code.
The ability to make a section of code read-only is something I've wanted
It sounds like you might be interested in Jonathan Edward's research. See, for example:
"The Summer of Code"
"What's next?"
"The future of programming"
Diffing and searching pictures is hard. Diff and search are very important to programmers. Using pictures instead of text is only a marginal improvement in many situations, it has some drawbacks, and it requires general acceptance before it's really worth doing (since you don't make things more understandable if your reader doesn't grok what you've done).
Plus, programmers have a million little tricks that make their lives easier, based on text representations of code, that they'd lose if you gave them code to read that was expressed in anything other than text. Sure, they might replace or re-implement those tricks over time, but in the short term they're gone.
You don't see lawyers switching from English to little back-of-a-napkin diagrams in contracts, either (the Creative Commons licenses try, but cannot make the picture be the formal representation of the contract). Probably for similar reasons.
If someone comes up with a programming language and IDE that, on balance, beats text-based ones; and successfully markets it; then you'll see the start of a revolutionary shift from text to a new format. If nobody comes up with any such thing, then we're not missing out. If someone comes up with something that is more productive but it doesn't gain traction because of independent advantages of other technologies, then that loss is the price we pay for free-market capitalism. Perhaps the ideas will be recycled eventually...
That said, integration between code and documentation could clearly be improved, and there are many efforts underway to do so, using various techniques with varying success. Again, the problem is that any particular cunning plan can in practice only really be implemented in one or a few languages and development environments at a time, and so has difficulty proving that it really is better. Embedding documentation in code is possibly the only universal advance since the invention of the API...
I think there's still a lot that can be done with text, though. For example, debugger technology makes a big difference to programmer productivity in certain common circumstances (namely: when a test fails or something else unexpected happens, but it's not obvious what the faulty assumption is in the code you're looking at). There may be lower-hanging fruit in terms of making programming better, than the actual business of expressing the program.
The last improvement I've seen is
syntax highlighting and context
sensitive help
Then you haven't looked much. Modern IDEs can do far, FAR more than that, namely show you the semantic structure of code (e.g. inheritance hierarchies) and even manipulate it (automatic refactoring) or enrich it with external data (such as who last changed a particular line of code).
I've used emacs, I like text macros. But, what I really want is parse macros. I'd like my editor to expose the machinery behind refactoring in such a way that I can write my transformations on the parse tree of the language itself.
For example, Python added += at one point when my code was littered with x = x + 1 lines. If I could have written a search and replace command that worked on the parse tree, I could have quickly cleaned up large amounts of my source code.
So, I want standard search and replace, but I want it at the level where the structure of my code has meaning, at the abstract syntax tree.
If you've ever used ReSharper, each of its refactorings and recommendations are written in the manner I describe, they find a pattern in the parse tree and suggest a replacement, or for a refactoring, apply a known replacement. I want access to that machinery for my own tasks!
Have you used Doxygen or similar for documenting your code? You can add links to images, and other file types (often stored in same directory as source code) that will get sucked into the generated documentation. I realize that this is one step removed from seeing the detail directly in you favorite editor but it definitely improves how we document our code.
Programming languages are a specialized form of mathematical notation, since you can express a programming language mathematically. Notation changes slowly, and so we don't get fast progress in our languages. Mostly, we advance when we come up with a new thing to fit into the notation, like using i to refer to the square root of negative one.
There are documentation schemes that allow you to embed things other than text. There was at least one programming scheme, Donald Knuth's Web, that allowed you to have a presentation and an execution version of a program (unfortunately, the base source code, the stuff you'd actually hack, was rather messy).
You could easily have a text editor that could treat comments as HTML, provided of course it could recognize comments as it saw them.
I've been thinking a lot about how to make coding faster and more efficient for the past years, always trying to keep it realistic and doing minimalistic implementations. Those are not revolutionary ideas, but since the original poster talked about the punching card to code typing transition, I thought of talking about other ways of communicating to the computer what we want to program.
My ideas are visual or vocal programming. The motivation behind is that there are only a number of ways a loop can be efficiently programmed, and an aware IDE could make some smart code substitution decisions depending on inputs other than typed lines of code.
Visual programming vs Coding: encapsulate (literally) code into "boxes" which have inputs and outputs, and connect them together across a horizontal timeline. This is a high-level concept that would be intrinsically interesting for multithreading development since you can have multiple lines or threads happening at the same time. Every process can be divided into a "box", no matter how you see it. Sending an e-mail in its most basic form is a box which takes an email as input and outputs a success/fail signal. Since the boxes and the lines are distributed across a timeline, the notion of time and event chronology isn't lost and feedback lines are possible.
Vocal programming vs Coding: The effectiveness of this technique would revolve around the effectiveness of the vocal syntax decided to create code and move the cursor. For example, you can say to the microphone "for variable zero to 10" and the system will automatically generate the following code placing the cursor inside:
for (x=0;x<10;x++){
// Cursor would be there after after the call
}
In terms of usability, you would need to be in a relatively silent room to minimize other sounds that might harm the voice recognition so this technology could be used in specialized environments mostly.
This is the result of my extensive programming experience using a wide range of hardware and programming languages. Let me know what you guys think, I'd love having a constructive discussion about that.
A few weeks back the "Intentional Software" created quite a buzz about their new language. I've yet to watch the presentation, but here is a quote from a review by Martin Fowler:
They started worryingly, with the
usual unrevealing Powerpoints, but
then they switched to showing the
workbench and the curtain finally
opened. To gauge the reaction, take a
look at Twitter.
#pandemonial Quite impressed! This is sweet! Multiple domains, multiple
langs, no question is going unanswered
#csells OK, watching a live electrical circuit rendered and
working in a C# file is pretty damn
cool.
#jolson Two words to say about the Electronics demo for Intentional
Software: HOLY CRAPOLA. That's it, my
brain has finally exploded.
#gblock This is not about snazzy demos, this is about completely
changing the world we know it.
#twleung ok, the intellisense for the actuarial formulas is just awesome
#lobrien This is like seeing a 100-mpg carburetor : OMG someone is
going to buy this and put it in a
vault!
Two quotes come instantly to mind:
"If it ain't broke, don't fix it."
"Use the best tool for the job."
Of course, although the core code is still written as text, alll the tools and libraries have changed massively since the days of punched cards.
This has been touched on by others, and it wouldn't revolutionise programming, but anyway...
I think it would be nice if code editors moved slightly beyond plain text editors. Even with syntax highlighting and code completion (which I think are incredibly good things), the editors of today (at least, the ones I use) still display exactly the same ASCII text (or whatever encoding is used) that is in the source files. I would be interested to see how well it would work if editors displayed, for example (some examples are more adventurous than others):
Comments in a text box with a light-blue background and no // or /* ... */ visible
Javadoc comments could have semi-rich text editing support (for those who do HTML Javadoc comments) (seriously, I would appreciate it if code editors rendered Javadoc comments as HTML because they're not the easiest to skim over when their HTML as plain text)
Functions in text boxes that could be collapsed to show only the signature (the collapsing can be done by current editors) and can be dragged around as boxes
Lines between function boxes to indicate how functions are connected
Zooming out so that rather than seeing a single source file (class in many languages) you can see multiple files and the way connect to each other (this would essentially be building UML-like diagramming directly into the code editor)
I think this (in my mind at least) would work without requiring additional markup in the source files so users of plain text editors wouldn't be disadvantaged by having all this extra markup cluttering the files.
Part of the problem might stem from the fact that when you don't code we don't call it programming: Assembling modular components using a GUI for instance.
You might be interested in these alternative programming "languages".
[Ladder][1], designed to mimic the way relay-logic-schemes work. Horrible IMO, but easy to understand for the old guys who did logic with sticks and stones. [http://www.amci.com/tutorials/images/ladder-diagram.gif][2]
[SFC, Sequential function chart][3], designed to simplify parallell programming. Code is written into boxes and these boxes can be placed paralell to each other and will thus execute simultaneously. By connecting the end of several boxes you can syncronize events. Very common for automation applications.
[Mathematica][5]!!!, Might not be the best programming language but the syntax highlighting(if you can call it that) is awesome! For example you can input a matrix by seeing the matrix nicly aligned instead of a huge double[][]. Graphs can be inserted in the code and the formatting of mathematical expressions looks like it does when you write on a paper. No more paranthesis-madness or long Math.PI expressions that really only need one character. And best of all, the files are just plain text even if it is rendered nicely in the editor!
Debuggers is also an area where lots of improvement has been done. Debuggers with replay are starting to come and also visual debuggers where data can be modified in real time. Edit and continiue is also a feature i wouldn't want to live withot.
WTF "new users can only post a maximum of one hyperlink", you will have to google the stuff i originally added to this post >:(
A brain-to-computer translator. Typing is the real
bottleneck. It really just needs to derive the algorithms I
think up and convert that to machine code.
I would say a lot of the newer languages are pretty great at
quickly creating algorithms. The improvements aren't so much
revolutionary now as they are evolutionary.
Dare I say it might actually be a new development language (perhaps even a new paradigm) to take us through such revolution;
I think you might want to take a look at Leo. This is one guys attempt at answering what you're asking about. I still can't wrap my VIM head around it personally, but others take to it quickly. It's not just a programming IDE, but more of an information organizer. It's written in Python, but I don't see why you can't code in other languages with it. The power of Leo is not so much the language, but the ability to express your thoughts and organize them whether it be in code, diagrams, images, or diagrams. Look over the tutorial and examples to get a feel for it. You might like it.
Automated semantic source code transformations, where a program can be reliably examined and manipulated by using an abstract interface/frontend to it that is aware of the underlying semantics.
So that source code can be queried and dealt with pretty much like a SQL database.
Allowing you to do static analysis of source code and refactor even complex source code by doing something along the lines of:
FIND CALLERS OF FUNCTION "foo" WHERE SIGNATURE("int","int","char*") AND RETURN_TYPE("bool");
...
RENAME MACRO "max" TO "maximum" IN FILE "macros.hxx";
RENAME NAMESPACE "prj" TO "project";
RENAME SYMBOL "OLDFOO" IN NAMESPACE "project";
RENAME FUNCTION "log" TO "show_log";
RENAME CLASS "FOO" TO "OLDFOO";
RENAME METHOD "FOO::inc" TO "FOO::increment";
...
CHANGE SIGNATURE IN FUNCTION "foo" WHERE SIGNATURE("int","int") TO SIGNATURE("double","double");
CHANGE SIGNATURE IN METHOD "myClass::handle" WHERE SIGNATURE("char") TO SIGNATURE("unsigned char")
MOVE FUNCTION "foo" in FILE "stuff.cc" TO "foo_funcs.cc";