Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Its my last semester of college and I have to do a big presentation in December. I plan on designing a small language that not only works, but also has some nifty features to go with it. Does anyone have any interesting syntax ideas or features that would impress my professors?
Note: I do not want to just copy a language and reimplement it. Im looking to do a little research and try some new ideas out.
I have a crazy idea.
There are compilers that compile compilers. This is fun enough by itself.
You can implement one in the MetaII style (read this other SO answer:
Are there any "fun" ways to learn about Languages, Grammars, Parsing and Compilers?)
What makes this doable for a student project is that the MetaII compiler is remarkably small, and
the technical paper (read the other answer) has everything you need in 10 pages
except some sweat, which you supply. And this fits
well in the time frame you have available (which is frankly pretty short for as student
to just sit down and whack out a compiler by himself).
MetaII's own description of itself is remarkably terse: only some 50 lines(!).
And since it can compile itself, it can compile enhanced versions of itself... so
you can use it to bootstrap much more complicated compilers. Normally, that's the
direction most people want to take it, since MetaII by itself is fairly simple.
Here's the crazy idea: You can also use it to compile less capable versions of itself.
The question is, how much can you take out, and still be able to climb back up the
metacompiler ladder? How small a compiler can you build that is still bootstrappable?
I know for a fact that MetaII has 2 items are removable, since I've done
this in the long distant past. I'm not going to tell you what they are becuase
that spoils the discovery process. But its good in a student project to take
on something that is already known to be doable, so you don't go down alleys
that have real dead ends.
One of the people I'm knew long ago apparantly tried to do this seriously. His goal was to reduce this to a very short string of characters... think of this as "compiler DNA".
Whilst I might not be able to answer your question directly, I am sure this will give you some insights from my own experience - given, for a final year project I also attempted my own scripting language (in C++) - although I am aware you're attempting a compiler so there might not be similarities. Please learn from my mistakes.
From experience:
What you imagine the scripting language will do (you type in a command, does something nifty like it fixes windows or something) and what it actually does (you type in a command, but minutes later it crashes) can often be two different things. Keep it realistic.
Aside from the brain imagining this fantastic finished product (with no inbetween), it also has a tendency of deluding itself on it's own capabilities (like 'other programmers made that mistake but I won't!'). Chances are you do make the same mistakes, or if not the same, different mistakes.
The brain has a poor ability to assess time required (if it's thinking 'it's just a hack job that'll take a month' - think again), and time it thinks is required should be multiplied between 5 to 10 times (if not more) to get an accurate idea of real scope needed. Keep to the lengthy end of the scope - worse-case scenario.
Unexpected pitfalls. Like 'how do I implement multi-precedented logic statements' and 'it's taking longer than I expected (see 3.)'. Be willing to give up complicated matters.
Design. Don't just look for ideas, think about whether or not it's a viable project, and look at how you're going to implement the groundwork before jumping to the complicated stuff (see 1.). Laying the groundwork early on can save you time. And don't forget design documents.
Research. Chances are that function you plan to write out, has already been written before somewhere. Research for it. This will save you time. Do not reinvent the wheel and do not be concerned about efficiency (university is about learning).
As one commenter said, start simple, get it working, then expand.
Best way to develop useful ideas, is to see what really bothers you about a certain task or certain scripting languages, and build it so you can eliminate or minimise that task. For example, I got annoyed by having to keep downloading files from a website and sorting it manually into specific folders - so I built a program to do that for me.
Don't go general-purpose for such a small project. Find a niche where you would like to be able to program a solution to an everyday problem. Off the top of my head, how about a constraint language for window placement in your X11 window manager of choice?
If you're just looking to have some fun, then you should try and create your own 'esoteric language'. 'Brainf**k' has kinda achieved meme status in the community (If I'm not wrong)
http://en.wikipedia.org/wiki/Esoteric_programming_language
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've been wanting to help out with an open source project for some time now. I want to do this for two main reasons. I am a strong supporter of foss and I want to gain experience.
I've struggled to find a project that I thought I would want to help with. There are many I would like to help with, but they are far to complex for what I would want to start with. However, I recently found a browser, uzbl, which seems like it is complex enough for me to be able to learn from, however simple enough for me to be able to wrap my head around.
It is a simple lightweight browser which uses webkit and gtk.
Now that you are familiar with my positon, here is my question.
What is the best way to go about understanding the code base?
Now I realize this is a subjective question. However, I feel if I have the suggestions of more experienced developers, I may be able to cut down on the wrong turns I make.
Should I familiarize myself with the libraries used first? Or should I look through the core code and concern myself with what goes in under the hood after I have a basic understanding of the global picture?
How do you guys go about understanding the code base of a new project?
Thank you for your time and effort.
First, compile and run it. With many projects, simply accomplishing that task will give you some understanding :-)
Second, it's good to have some problem to solve. Some small task, like fix a minor bug somewhere. Just debug, search for the bug origin, try to fix it. Then run unit tests (if any), see what else you broke with your fix. Investigate that, too.
Then repeat. A dozen of bugs, preferably in different areas, give some better understanding of the codebase.
After that, I usually start wondering around the product, just looking how it works and playing with it. Natural curiosity takes over sooner or later, and I find a feature that interests me. In a "wow, I wonder how it works" kind of way. Then I try to sketch a high-level design for that feature myself. Along the lines of "what would I do if I had to create this feature? Very briefly, just in my mind, no fancy diagrams and whatnot.
In doing so, I inevitably find myself in need to know more about the system: after all, you can't design a fully isolated feature, can you? You'll have to interact with the rest of the system, and you need to know how. So I go into code and find out.
Then, a moment may come when I realize that I really don't know how to design this little part of that feature. I think, and I think, and I think, and I just don't know. So then comes the sweetest part: I go into the code and look how is it designed in the first place. Sometimes I would be disappointed in the project. But more often, I would be disappointed in myself. But that's exactly what's precious: that's how I learn.
I have found two things (in addition to the answer by Fyodor Soikin) that really help. One is getting doxygen to do document everything for me. It makes it a lot easier when I can go through the function declarations, and click the data structure which is supposed to be passed in so I can see all the members it contains (if there is no current documentation you can just set EXTRACT_ALL = YES). I also find it very useful to compile the project with debuggin symbols then run it in gdb so that you can follow it from start to finish.
I would look for their tests first, and look at those. If there aren't tests, I probably wouldn't bother with the project. If there are tests, they should be instructive as to how the software works. Step through the tests in the debugger to understand how the high level components fit together.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In short I'm creating a 2D mmorpg and unlike my last "mmo" I started developing I want to make sure that this one will scale well and work well when I want to add new in-game features or modify existing ones.
With my last attempt with an avatar chat within the first few thousand lines of code and just getting basic features added into the game I seen my code quality lowering and my ability to add new features or modify old ones was getting lower too as I added more features in. It turned into one big mess that some how ran, lol.
This time I really need to buckle down and find a design that will allow me to create a game framework that will be easy to add and remove features (aka things like playing mini-games within my world or a mail system or buddy list or a new public area with interactive items).
I'm thinking that maybe a component based approach MIGHT be what I'm looking for but I'm really not sure. I have read documents on mmorpg design and 2d game engine architecture but nothing really explained a way of designing a game framework that will basically let me "plug-in" new features into the main game.
Hope someone understands what I mean, any help is appreciated.
If you search for component-based systems within games, you will find something quite different to what you are actually asking for. And how best to do this is far from agreed upon just yet, anyway. So I wouldn't recommend doing that. What you're really talking about is not really anything specific to games, never mind MMOs. It's just the ability to write maintainable code which allows for extension and improvements, which was a problem for business software long before games-as-a-service became so popular and important.
I'd say that addressing this problem comes primarily from two things. Firstly, you need a good specification and a resulting design that makes an attempt to understand future requirements, so that the systems you write now are more easily extended when you come to that. No plug-in architecture can work well without a good idea of what exactly you hope to be plugging in. I'm not saying you need to draw up a 100-page design doc, but at the very least you should be brainstorming your ideas and plans and looking for common ground there, so that when you're coding feature A, you are writing it with Future feature B in mind.
Secondly, you need good software engineering principles which mean that your code is easy to work with and use. eg. Read up on the SOLID principles, and take some time to understand why these 5 ideas are useful. Code that follows those rules is a lot easier to twist to whatever future needs you have.
There is a third way to improve your code, but which isn't going to help you just yet: experience. Your code gets better the more you write and the more you learn about coding. It's possible (well, likely) that with an MMO you are biting off a lot more than you can chew. Even teams of qualified professionals end up with unmaintainable messes of code when attempting projects of that magnitude, so it's no surprise that you would, too. But they have messes of code that they managed to see to completion, and often that's what it's about, not about stopping and redesigning whenever the going gets tough.
Yes, I got what you want...
Basically, you will have to use classic OOP design, the same one that business software coders use...
You will first have to lay out the basic engine, that engine should have a "module loader" or a common OOP-style interface, then you either code modules to be loaded (like, as .dlls) or you code directly within your source code, using that mentioned OOP-style interface, and NEVER, EVER allow a module to depend on each other...
The communication, even inside your code, should be ALWAYS using a interface, never put "public" vars in your modules and use it somewhere else, otherwise you will end with a awfull and messy code.
But if you do it properly, you can do some really cool stuff (I for example, changed the entire game library (API that access video, mouse, keyboard, audio...) of my game, in the middle of development... I just needed to recode one file, that was the one that made the interface between logic, and game library...)
What you're thinking about is exactly what this article describes. It's a lovely way to build games as I have blogged about, and the article is an excellent resource to get your started.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have noticed I do not code as much as I use to. Today I dedicate more time to analysis and design, then I communicate that design to programmers. Then they do the coding. This has affected my coding productivity, because I must consult references and rely on intellisense. Things are becoming more complex everyday
Now, here is the irony. If I were to hire a programmer and ask him/her to sit in front of a computer, I may ask to do some coding and I would check abilities. I would evaluate them based on their use of memory vs. consulting references. Maybe I will prefer that programmer who did not consult too much, but who knows what they are doing.
What is your opinion and experience?
I would say that a developer who knows how to find the answers is better than one who has an overall good knowledge already. I find that intellisense is a good tool for finding answers, besides it is too much to remember all method names, arguments, overloads, etc.
I use memory to get me into the right general area (e.g. knowing which classes to use or at least which namespace they'll be in) and then often Intellisense/MSDN for the exact method name or arguments to use.
Having said that, Stack Overflow is improving my ability to code without any references (or even compilation) - I'm sure code will just work out of the box for me more often now than it used to. (I tend to post and then check the code works, add links to MSDN etc - assuming I'm reasonably confident in the approach.)
Someone knowing what resources are available, and how to find the answers, and how to effectively debug - these are qualities I look for now in prospective employees.
I used to consult my memory only, but two things have happened:
Class libraries have gotten larger, so has the number of languages available
The ratio of programming-related memory to personal-life-related memory has shifted away from code
Programming today is also eight times harder than it was when I started. I used to work on 8-bit machines, now I'm working on 64-bit ones. :)
I once was at a job interviewed with the CTO of a company. He asked a question based on a real life problem the company had a while back and solved. It was a multi step problem.
I was standing in front of a whiteboard working through my solution and struggling through a particular part, a part I would use google for before even attempting it, had I been tasked with solving this problem for real instead of for an interview. He asked me at that point, "would you do anything different if this wasn't an interview question." I responded, "Yes. I would exhaust all possibilities of using a third party component for this part of the task and look up the solution, because it is a well defined problem thats been solved several times." There was a bit more discussion where I justified my answer, explained exactly what I would research, and I solved some other parts of the question. In the end I was offered and accepted the job, partly because of knowing how to find out what I didn't know.
Being able to use references is as important as being able to code from memory. Obviously, if you are a one language shop, and want people proficient in that language,the person should be able to write a complete hello world app in notepad. Interview problems should focus on small problems, and one should not worry about small syntax errors. This is why a whiteboard is the best IDE for interview questions.
Unless you demand all your coders use notepad and don't give them internet access, don't be as concerned by the syntax. If you do sit them down in front of a computer, worry about the finished product as well as the technique used to get there.
I'm a PHP programmer in my early 30's. I rely on PHP's excellent documentation, for several reasons:
Programming concepts don't change. If I know what my object models are and how I want to manipulate data, then there's dozens of ways to implement the details. The details are important, but a better grasp of the design and structure is more important
PHP has notoriously inconsistent functions. One string function might use ($needle,$haystack) as parameters, and another might use ($haystack,$needle). Trying to keep them straight isn't worth the hassle when you can just type php.net/function_name and get the reference.
I don't rely on intellisense, simply because I haven't found a decent IDE for PHP that does it well. Eclipse is ok, but it's not fantastic. Netbeans gives me 'PHPDoc not found' for all the built-in PHP functions whenever I install it. There's nothing that I've found so far that beats out the documentation.
The bottom line is that the ability to memorize functions isn't indicative of coding ability. Obviously there's a key set of basic functions that a good programmer will know just from extensive usage over time, but I wouldn't base a hiring decision on whether someone knows substr_replace vs. str_replace from memory.
Because I've read either the documentation, or articles, or a book on a subject, the things I learn on a topic are organized. The result is that, if I can't bring something up from memory, I can probably find it quickly through IntelliSense or the Object Browser.
Worse come to worst, I can pick up the book again; something these youngsters are not being taught to do.
John Saunders
Age 51
Pretty much Google + Old Projects + my memory (of course)
References will not solve your problems though, its only for the nuts and bolts, the higher level of problem solving is the actual "programming" part IMHO.
I tend to use Intellisense and Resharper much more than I used to before, but this has helped my overall productivity. If I can get the idea of how I want to solve something and then use tools to get the more boring parts like class names and function signatures, why shouldn't I use the tools I have? I feel relieved that Jon Skeet has a similar approach it seems.
I rely on my bookmarks and books... and my ability to use them effectively. I have multiple books above my desk, including a copy of the ISO C90 standard. Moreover, I use Xmarks to have access to my bookmarks wherever I go. Sometimes, I make a pdf out of a particular page and upload it to my web-site if it is important enough.
Sometimes the information provided by the resources I use makes its way into my terrible memory... maybe.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Somehow I've got the feeling that many projects become heavily overengineered so every possible change-request can be tackled with the effect that the change-requests that occured are very hard to implement.
Somehow I get that feeling in nearly every project I'm currently working on. It is like everyone is thinking "which cool api, framework, etc. can we add to the project to tackle this and that aspect" without evaluating if it is practical or needed.
Does anyone else feel the same or what's the opinion of the community here?
Yes.
-- MarkusQ
I find that, while some older companies with 'senior' senior management tend to be extremely rigid with how their business code is created, newer companies completely lack a backbone of what software they use to get the job done.
The problem you describe sounds like people are viewing problems at too high a level and want to find a way to solve it in one go. Creating a working toolbox (think standard libraries) would help them out in the long run.
I particularly enjoy the UNIX way of things: Several tiny utilities that do one thing and do it really well.
Definitely - I think people get 'robust and modular' and 'overengineered' mixed up far too often.
I think Dave Winer captured the cyclical nature of this phenomenon well:
The trick in each cycle is to fight
complexity, so the growth can keep
going. But you can't keep it out,
engineers like complexity, not just
because it provides them job security,
also because they really just like it.
But once the stack gets too arcane,
the next generation throws their hands
up and says "We're not going to deal
with that mess."
Guilty as charged. Three levels of abstraction and six config files is just more fun to implement than a simple flow control branch.
Overengineering is a danger in any project, large or small. When writing for code extensibility, there's always a trade-off between writing code that is sufficiently generic and extensible to allow for future development and code that is specific enough to make the task at hand easy.
Every "future hook" has a cost and should be evaluated in the light of that cost, the probability that it will ever be used, and the cost of refactoring later in the game. "More generic" is not always better.
As for using a hot, new framework or API, I think project managers should take a gentle hand in this. With development being such a fast-moving field, hands-on self-training is part of the price of doing business (but obviously should be kept reasonable.)
I've only encountered that with Java people: "Lets use spring!" And hibernate! I found this cool validation package as well! And this one will create XSLT to create XML forms to create the javascript!"
By the time I find all the jars and get them to play nice, there are dozens of classes I have to be familiar with. And then they want to abstract away all those pieces! "We might switch spring out. Or not use hibernate, so we should abstract those away". Add another dozen hacky wrapper classes.
By the time its all done, 50 lines of psuedo code has turned into several thousand lines of making the "cool stuff" work, and about 100 lines of business logic trapped within its hairy, hacky, bug-ridden hell.
I'm guilty of it myself, too, but thats only because I'm bored and have time to kill.
The key thing to keep in mind here is time. A "simple" project that is knocked out of the park on day one by an Excel spreadsheet or a web page can quickly expand in both its audience and scope to become an unsustainable monster.
Under-engineering is a danger, too. The world is full of "practical" people who will mock any efforts that are contrary to their opinion. Nobody remembers the person who disagreed a year later when the "simple" solution can't be sustained.
The trick is to balance the right degree of engineering and be able to adjust when things change.
I've been bitten a few too many times by applications that I've thrown together quickly which have subsequently become "critical" apps. Then I have to almost rewrite the darned thing. I just assume now that it will become critical and so I "write it right" the first time. Saves me time and effort in the long term. So oddly, it's about laziness.
Today's xkcd is the absolute truth:
I find that overengineering is a byproduct of boredom. I believe Jeff and Joel covered this in a podcast, but the idea is that coders who often overengineer may just be in a rut and need a change of pace (Jeff and Joel suggested that they be allowed to do different jobs like QA).
Yes. I think people nowadays think more about how something should be done, and whether "it's the right way ..." and so on, than just picking the simple solution which will equally get the job done. If you're not asked to expand it, then don't think about expanding it.
I think this is a problem, but not as big as it seems and that there are good reasons for it.
The problem is that most projects that are underengineered will die a quick death while the overengineered ones can survive. Thus, when you look at still living project, there is survivorship bias.
And, even if you are a good architect that aims for "just good enough", if in doubt you will use the more flexibe, scalable, ... (i.e., overengineered) solution. Because the failure mode if you do not meet the requirements (whatever they may be) is usually much worse than what happens if you exceed them.
I'm yet to work on any real world problem but I've read enough people blogging about this to assume there is a problem.
Absolutely. But it's not just developers, it's users too. "I want this and that and the other in order to improve communication and increase productivity!".
I'm amazed at how many of these types of projects we've solved by just putting a shared folder on a file server.
As others have said, I've had too many 'small' projects become big ones and the short cuts taken become paint.
There is a place for a quick-and-dirty solution and in trying to follow the YAGNI mantra, I've created simple apps with no engineering.
With that though, you are not going to be able to jump into a million line system and develop the 'well engineered' system without practice on smaller systems.
I've taken to always following the developed architecture of our company in all projects because it helps me to work out solutions in line with the engineering principles we are trying to follow.
What you practice, you perform, so always do your best.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm not a full-time software guy. In fact, in the last ten years, 90 % of my work was either on the hardware or doing low-level (embedded) code.
But the other 10% involves writing shell scripts for development tools, making kernel changes to add special features, and writing GUI applications for end-users.
The problem is that I find myself facing significant holes in my knowledge, often because it's been years since I've done "X", and I've either forgotten, or the environment has changed.
Every so often, there are threads on TheDailyWTF.com along the lines of "WTF: the guy spent all day writing tons of code, when he could have called foobar() in library baz". I've been there myself, because I don't remember much beyond the #include <stdio.h> stuff (for example), and my quick search somehow missed the right library.
What methods have you found effective to crash-learn and/or crash-refresh yourself in programming environments that you rarely touch?
Ask developers you know that work in the environment that you are interested in.
Search the web a lot.
Ask specific questions in relevant IRC channels (Freenode is great).
Ask specific questions on StackOverflow and other sites.
There really isn't any substitue for being "in the daily flow" of the programming environment in question. Having a good feel for the current state of the art is something you only get from experience, as I'm sure you can verify in you own areas of expertise.
i try to keep up with general news about languages i'm interested in but aren't necessarily using at the moment. being able to follow the general changes helps a lot for when you have to pick it up again.
beyond that, i personally find it easiest to grab an up to date reference book, and code a few basic things to get me used to the environment again, ie as a web programmer i'd make a simple crud app, or a quick web service/client.
For frameworks/APIs (such as a JavaScript framework or a widget library):
Quickly scan through the entire API documentation; get a glimpse of all that's out there instead of picking the first method that seems to fit your needs.
If available, glance at the source code of the
framework to see how the
API was intended to be used. Seeing what's behind the curtain helps. And also
some of the methods will have been used
internally, showcasing their true intents.
Don't necessarily always trust existing code (Googled, from co-workers, from books) since not everyone does the due diligence to find out the most proper way to use an API. Sometimes even samples in API documentation can be out-of-date.
In newer full-featured environments like Java, .NET, and Python, there are library solutions to almost every common problem. Don't think "how can I program this in plain C", but "which library solves this problem for me?" It's an attitude shift. As far as resources, the library documentation for the three environments I mentioned are all good.
The best solution I think is to get a book on the topic / environment you need to catch up on.
Ask questions from developers who you know who have the experience in that area.
You can also check out news groups (Google Groups makes this easy) and forums. You can ask questions, but even reading 10 minutes of the latest popular questions for a particular topic / environment will keep you a little bit "in the know".
The same thing can go for blogs too if you can find a focussed blog. These are pretty rare though and I personally don't look to blogs to keep me "in the know" on a particular environment. (I personally find blogs most popular and interesting in the "here's something neat" or "here's how I failed and you can avoid it" or "general practice" areas.)
In addition to the answers above, I think what you are asking for will take a significant amount of your time, and you must be willing to spend that time to achieve your goals. My method would be pretty much the same as Owen's answer; get a reference book or tutorial and work through the examples hacking in changes as you go to experiment with how any given thing works. I'd say as a bare minimum, allocate a hour to do this every other day, in a time that you know you won't be interrupted. Any less, and you'll probably continue to struggle.
The best way to crash-learn is simple, simply do it, use google to search for X tutorial, open your favorite browser and start typing away. Once you reached a certain level of feeling with X, do look at other people things, there is lots of open source out there and there must be someboby who has used X before, look at how they solved certain problems and learn from this, this is an easy way to verify that you are 'on the right track' or that you're doing things or thinking in patterns that other people would define as 'common sense'.
Crash-refreshing something is much easier since you have a suspended learning curve already, the way I do this is to keep some of the example you did while writing or keep some projects you did. Then you can easily refresh and use your own examples.
The library issue you mention here well, only improving your search skills will improve that one (although looking on how others solved this will help as well)
Don't try and pick up every environment.
Focus on the one that's useful and/or interesting, and then pick a few quality blogs to regularly read or podcasts to listen to. You'll pick up the current state of the environment fairly quickly.
Concrete example: I've been out of the Java world for a long time, but I've been put on a Java project in the last few months. Since then I've listened to the Java Posse podcast and read a few blogs, and although I'm far from a Java guru I've got back up to speed without too much trouble.
Just a though. While we are working on our code we know that we need to work very hard to optimize the critical path, but on non critical path we usually don't spend to much effort to optimize.
From your description you are working 90% on embedded and 10% on rest, lets assume that in 50% of the rest you are spending more time that needed. So according to my calculation you are optimizing about 5% of your work flow ...
Of course the usual google/SO/forums search is useful before you doing something new, but investing more than just that is waste of time for my opinion, unless you want to waste some time just for fun or general education ... :), but this is another story.
By the way I'm in same position and last time i needed some GUI and used MFC (because i used it sometimes 10 years ago :) ) and i perfectly understand that i probably will get better results with C# and friends, but the learning curve just not justify this especially knowing that i need mix the C code with GUI.