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
From time to time you come across some interesting code or programming challenges,
such as the ones in Project Euler, some job interview challenges like greplin, or any of the other script challenges that are posted here.
All these require some fast, agile programming language with some kind of quick way to see the results, preferably command line. There's no need to worry about readability of the code or such. You just need an answer, and fast.
What is a good language to solve these challenges? What is the best hands-on method for solving, if you have to choose a language and learn it from the start?
Project Euler tells you that lots of languages are suitable. Those problems are solved in every language from Perl to C#.
The language you should use for challenges is either the one you know best or the one you're trying to learn right now.
If you mean fast coding, rather than fast execution, I suggest looking at Python. It's very high level (thus, you can code powerful things quickly) and has an interactive mode that lets you see results immediately, which sounds like what you're looking for.
Reading your description:
You just need an answer, and fast.
I assume you are talking about runtime. If this is the case, C++ is the way to go.
However if you just started programming and you need to learn the basics, I would suggest Python.
You need an answer and fast
Only if that is the way you find programming acceptable.
Or if you intend to not gain experience in teamplay programming.
You can't fool yourself :/
I just gave this advice to a similar question for a game development language choice:
1) What is my goal?
2) What engine is going to help me , or framework, platform, what are you depending on?
3) What languages can I use to accomadate step one and respect step 2
Basically what you can do is skip step 2 really.
And it's really about what YOU want. If you REALLY want to spend a lot of time working to quick results ( Which I can respect, I'm not trying to sound all-in attack mode here), you should consider C++. It allows you to dig deep, but it can be quick , even sloppy, if need be. But you do need a little XP in it.
Related
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 5 years ago.
Improve this question
Currently I am working on porting a benchmark application to another system. I am working alone, so I am frustrated about which software methodology I really have to use. Please give me some ideas.
I am going to assume you're wondering which Agile approach to use on your project as you tagged your question accordingly.
Agile is mainly about:
Delivering working software continuously and regularly
Aiming at technical excellence and avoiding technical debt
Improving the way we work and retrospecting regularly
I'd say whatever you use, even your very own approach to software development, if you can check those three items from the list, then you're pretty much Agile to me. Some people need strict guidelines and artifacts and that's fine, they help people become Agile but are far from being mandatory despite the dogmas out there.
Here's how I would approach your situation.
Take a step back and try to identify the most important features or abilities of this benchmarking application. By most important, I mean those features that the people using it in the end cannot live without. Once you have a list of those, put them on post-it notes, index cards, trello, jira or whatever tool you want to use.
Split each of those features into full-stack chunks of functionality that are business driven. I'm not talking about technical tasks here, but smaller features usable by actual people. I usually opt for the "Grandma Driven" approach here, asking myself "would grandma be able to understand what I'm trying to do?". It's just to make sure I'm focusing on a full stack feature and not a technical task like "populate database". One way to see this is also by applying dimensional planning to each of the features you identified (http://www.xpday.net/Xpday2007/session/DimensionalPlanning.html).
Set yourself an iteration length (I usually go for 1 or max 2 weeks when I'm working alone) and get to work one small item at a time. Don't write code for later, only what you need to solve the problem at hand. Quality is not an option. Focus on good coding and testing practices.
At the end of your iteration, check how many features you implemented and put that number somewhere on a chart, in a google spreadsheet or whatever. This will help you see if you're on track. Get feedback from colleagues or any potential users of the system and reflect on that feedback. It's not because you're porting to another platform that you can't make it better.
If you end up not having small enough granularity with what's left or not enough stuff in your list of things to do, spend some time repeating steps 1 to 3.
At the end of each iteration, keep tracking how many items you did just to see if you still have a good enough pace. If not, ask yourself why and change something in the way you work or get help. Again, your main focus is to make progress and deliver software that works at the end of each iteration.
It might not answer your question and I know I didn't give you an answer of the type, use kanban, scrum or whatever but I truly believe it's not appropriate in your specific case and would only generate overhead and boredom for you.
Hope that helps anyway, good luck with your project.
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
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 6 years ago.
Improve this question
So I have a project - which I guess can be considered a relatively 'large-ish' project, that I want to build.
However, I am completely new to Rails. I am intimately familiar with UX & front-end development, but dealing with the back-end is new to me. I really want to learn though, and I remember DHH famously saying that the best way to learn is just to do it.
However, I was recently speaking to an experienced Rails developer and he said it might be better to build smaller projects - so I can learn in shorter durations and not get discouraged. Then I spoke to another experienced Rails developer and he said that there is something to be said about jumping in the deep end.
So what do you guys think? What are the pros and cons of both?
Jumping in at the deep end is fine if you know enough to plan your project carefully. If you don't know anything about MVC architecture, you will probably have a really hard time planning out the database and program elements you need to get from point A to Z.
Properly planned, you can do a project by creating successive (fully functional) iterations with each one a step toward completely fulfilling your requirements. For example, with a blog you could first build a system for entering posts into your DB, then build a display function, then build tagging, then build commenting, etc.
If you don't know anything about Rails and don't know MVC, then at least a couple of tutorial level projects will be real helpful for getting you familiar with the environment and the architecture concept.
Honestly it's a different answer for everyone. Which do you think would benefit you most? If you think you would be too overwhelmed by a large project then start small and continue when you feel comfortable.
What would I do? I'd jump straight in. No matter which you choose to do your larger project is likely to contain more tasks, issues, and ultimately a lot of troubleshooting. That's a good thing, though.
The nice thing about using Rails is that it's fairly easy to build all of your models and database elements with all of its generators. Then you can simply copy any view or controller logic you've already implemented.
Some time ago, a smart developer told me to avoid "analysis paralysis" and to start designing my solution as soon as I could. In my experience I've learned that every large project could be divided in smaller ones. Rails, and all the frameworks built like it, are good on both concept:
- it helps you in designing a solution by dividing Data, Business Logic and Presentation.
- it helps you in passing from idea to code
- it has some convention that could shorten your learning curve
- it's good for DRY coding
So since you already have a project go with it. If you can find another crazy developer that is willing to help you, you'll discover that rails is good also for teams and at the same time you'll learn how nice is to work together, share ideas and discuss.
So... Time to go, type at your prompt:
rails new my-largish-cool-project
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 9 years ago.
Improve this question
Currently I am learning Smalltalk. I do this because I want to learn as much as I can in one week about a new programming language in order to improve my skills. Next week I will try something else.
So far I am able to read Smalltalk code but I have a very limited experience in writing. Can you recommend me any small size project that will help me understand better this language in a short time period?
Look into a book Squeak by Example, there are many examples to work on and practice. After a while you'll be very well prepared for some real, yet mini project.
I think you need only few days for a book with examples, so this is well spend time even if you have just one week.
I really, really like The Laser Game Tutorial
Tutorial: Squeak Development Example for Squeak 3.9
A.K.A. "The Laser Game Tutorial"
This excellent tutorial by Stephan Wessels will guide
you through installing Squeak, to creating a fun game using the Morphic graphics system, all > while observing solid object-oriented design principles
It is divided in 6 Sessions so 1 each day although I must say each session has taken me two hours or so.
Perfect for your objectives.
Anything not too trivial goes well. If you plan going on squeak, I'd propose you to write a card game, lottery or something else such.
It'd be more useful for you to find out some example code though. What prevents you from writing C in smalltalk?
Just do whatever you'd do in the language you already know. Taking a small task like writing a simple TODO list or even simple blog will undoubtedly improve your Smalltalk skills.
And remember to be easy on yourself. Expecting too much too soon can be intimidating.
If you would like to try something different, check out GNU Smalltalk Koans at http://skim.la/gnu_smalltalk_koans/, a set of tests to teach you Smalltalk in the tradition of Edgecase's Ruby Koans and Python Koans.
It promises to incrementally deepen your understanding of the language through tests.
You can have a look at Programming with robots.
I think the BotsInc material can be mastered in one week - although the time taken can vary. There is a Free book version for download available. And for small real world projects there is NXTalk announced for
early this year.
I really enjoyed Ted Bracht's Dolphin Smalltalk Tutorial:
http://www.amazon.co.uk/Dolphin-SmallTalk-Tutorial-Ted-Bracht/dp/0201737930
It takes you set-by-step through a GUI-based windows application. It's a pretty good tutorial.
Apart from the The Laser Game Tutorial. (that I recommended in my previous answer)
There is the "The Bowling Game"
Article: Discovering Better Code
Series
A.K.A. "The Bowling Example" A guided
tour through the mind of a
Smalltalker: How to build a business
model from the ground up, factoring it
along the way. If you don't understand
how Smalltalkers think or why they
think that way, you need to read this
series.
The really nice thing about this project is that it is like being the pair-programmer of a great developer.
The author Ron Jeffries is one of tho founders of Extreme Programming and a book author.
So it is a really good resource. I wish more tutorials where written like this.
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 3 years ago.
Improve this question
Uphill about 5 years ago my career was going fairly well, but separation, family deaths and a bit of illness caused me to make a couple of BAD career decisions, and I ended up in a dead end job doing mainly vb 6, though it was the end as mid to late 30, but was recently handed a break, working with a forward thinking vb.net company and I took the chance with both hands, been there 5 months now
Thing are going ok, spending a lot of time in places like this, and reading books, but coming from a C / Machine Code / VB 5 &6 background, I'm finding the little intracity of .NET lost on me, if I write code I wouldn't think to use delegates for example, has anybody got any advice on making the 'brain' VB.NET jump, or training I should be looking at (bear in mind that I'm not rich)
Thanks for your time
Taking a introductory .NET course will be a good investment. It gives you a chance to focus on .NET for four or five days and build a good foundation.
The other choice is to use online resources and do self study. One suggestion (out of the ton that are out there) is to follow one of the webcast series available at http://www.microsoft.com/events/series/modernsoftdev.aspx?tab=webcasts. Although they are a little dates (they focus on Visual Studio 2005) they are designed for people like yourself.
The other suggestion is to find a local .NET user group. Spending some time with people and sharing exeriences will help you learn and will give you a chance to do some networking.
Just work with the .NET framework, and the use of things like delegates or interfaces will come to you. Since you already know that they exist, you will find yourself in a situation where you think "Gee, this can easily be done by using a delegate!" If that happens, use a delegate.
I think this is better than looking for a way to use all those shiny .NET thingies - they are useful, but only if used correctly.
IMHO, I would suggest not moving to vb.net at all, but instead utilizing your C background, and making the move to C#. The reason for this is, you already know the syntax and that VB.net is not enough like VB6, to make it as easy a move as you might expect. Plus you're more "likely" to come into contact with developer's who use the more advanced features of the framework etc.
This might be a slightly controversial statement but I firmly believe that in order to re-ignite a career it's sometime better take a mental leap to something new. You'll find that everything you've learn prior to this, will cement the new knowledge you'll be acquiring.
In addition find a personal project you can get highly motivated about, with a tangible end goal/deliverable, that will make learning your new skills much more fun.
It's not like C/Machine code programmers aren't in demand... They're growing increasingly rare as developers are breast-fed with Java or .NET nowadays :)