Related
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.
I would like to hear from you folks that have achieved a high-level of proficiency in F# (and also in functional programming in general too) what should be my steps from now on to become a better/professional F# programmer?
I already know much of the F# syntax and have some years of experience with C++. My goal is, as an engineer and mathematician, to design better scientific libraries (linear algebra packages, partial differential solvers, etc.).
what should be my steps from now on to
become a better/professional F#
programmer?
Keep coding everyday :)
I jumped on the F# train in Sept '07, before that I had a boatload of C# experience. It took about 3 months or so for me to stop writing code as C# with a little funnier syntax and start picking up on the right coding style :)
Tips and things that helped me:
I found that F# makes it really hard to write non-idiomatic code, really easy to write good, clean code. If you find yourself fighting the compiler, 9 times out of 10 your doing something wrong. Go back to the drawing board and try again.
The entire concept of immutability was a mystery at first, but implementing all of the data structures from Okasaki's Purely Functional Data Structures was hugely helpful.
During some slow days at work, between '08 and '09, I wrote a wikibook. I haven't looked at it in a while, but I'm sure its really bad --- but, the experience of explaining the language to others was a good jumpstart for someone like me who normally wouldn't have enough motivation to start a pet project in F# :)
Map, Fold, and Filter are your friends. Try to express algorithms in these functions rather than implementing a loop with recursion.
Non-tail recursive functions are almost always easier to read and write. See here.
Project Euler. Lots of people recommend it, I didn't find it particularly helpful at all. You might get more use from it than me if your a mathematician, however.
<3 unions! Use them!
Falling back on mutable state -- big no-no. At least for beginners. The worst beginner code is full of mutables and ref variables. Immutability is an alien concept at first, so I recommend writing fully stateless programs for a while.
Still, the best advice is just keep coding everyday.
Hope that helps!
-- Juliet
Like any other language now that you know the syntax and the basics it's time to write code and more code.
Make sure you have the core concepts of functional programming down.
Work on a large project so you also get familiar with the large and not just the small.
Write a few immutable data structures.
Work on a large project without using inheritance.
If your familiar with design patterns implement some of them in a purely functional way and notice how some of them disappear.
F# is about mixing functional and OOP styles. Once you've done a fare amount of abstraction without inheritance bring it back and start mixing the styles together. Find a balance.
Since your goal as an engineer and mathematician is to design better scientific libraries may I suggest as a learning exercise working on a video game style simulation. Something that involves physics and math but also requires control of state.
I can only agree that trying to explain functional programming to others is a great way to learn it. I spent a lot of time about thinking the structure of my F# book and I think it really helped me to understand how functional concepts relate. Even giving a talk on F# in your company or to your friends should have a similar effect.
When I started learning F#, I started working on the F# WebTools project. I think this was quite useful, because many components of the project were perfect for functional programming, so I learned many functional tricks (because they were the best way to solve the problem). The project processed source code tree of F# and translated it to JavaScript, so I was using a lots of recursive functions and discriminated unions.
The area you're working in is quite different than my, so I cannot give you any specific advice, but it is a good idea to write programs in a clear functional way - even if you think that it would look nicer if you wrote it in the C++ style. When you write it, you'll probably find some way to simplify your code.
So, I think that the tips I could give are:
Try to explain F# to others - this helps you to organize ideas in your mind
Pick good problems to start with - e.g. algorithmic problems, processing tree structures, etc.
Write as much F# as you can and don't be afraid to start with a solution that does not look perfect to you - I rewrote my first program so many times!
you very probably don't want to hear from me as I have not achieved a high level of proficiency with F#, but I have set myself the goal of getting there (much like your self).
I thought I might suggest what has turned out to be my biggest learning tool: Stubbornness.
I set my self a large-ish project (a game, just as gradbot suggests). I then decided to code using as much immutable data as possible regardless of the performance costs.
Then if I couldn't find a way to use immutable data I'd come here and ask for help.
The hoops this stubborn approach forced me to jump through has been a brilliant learning exercise, as (just as Juliet mentions) F# allows you to write really ugly C# if you let your self get lax.
Right now I have tile based 2D world and a little man who can find his way to the treasure and back home again using A* path-finding ... The only thing I mutate is the title of the window it's displayed in.
I only got serious about learning F# towards the end of July (I'd dabbled before then) and this project has taught me a huge amount, along with the help of the guys here at StackOverflow.
The other answers do a good job of suggesting ways to practice your F# writing skills, which is obviously very important. However, something which doesn't seem to have been emphasized much is reading F# code, which is just as important in my opinion. There are a lot of people doing cool stuff with F#, and one of the best ways to learn about the different corners of the language is to read about what they're doing. This will help you pick up idiomatic style and will also expose you to more design patterns, language features, and functional programming techniques than you would be likely to encounter if you were just solving a problem using F# on your own.
The F# blogs syndicated on Planet F# are a good place to start, but there are also several excellent books and presentations on the language.
This only answers part of your question, but as you talk about wanting to create libraries in F#, the F# component design guidelines just came out:
http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/fsharp-component-design-guidelines.pdf
If you are interested in scientific libraries I suggest you to take a look at Jon Harrop's F# for Scientists.
Also to catter for your mathematician side I suggest you to read Doets-Van Eijck The Haskell Road to Logic, Maths and Programming, although written in Haskell, you will certainly be able to follow most of the text, and re-implementing the samples in F# could be a nice exercise.
I'm a C++-Programmer. But now i have to learn Pascal/Pascal. Are there any websites, documents around that can teach someone with my knowledge the difference?
It shouldn't be too difficult to pick up. C's design was influenced by ALGOL and Pascal, so the semantics and logical flow are going to be pretty familiar. You can get an overview of the differences between basic Pascal and basic C here.
But you tagged this as Delphi and you mentioned C++, which implies that you'll need information on OOP techniques. Try this article or this one, which compare object-oriented programming in Delphi with C++ and other languages. Both are a bit dated, but most of the basic information in them still applies today.
If you have any specific questions about language features, feel free to ask them here, and welcome to Stack Overflow!
You can check Essential Pascal written by Marco Cantù, is a introduction to the Pascal programming language. you can download a free copy from here.
Another excellent site for beginners, is Delphi Basics, this web site provides help and reference for the fundamentals of the Delphi language. It gives an introduction to the Delphi Object Oriented Language for newcomers.
A website that helped me a lot when I learned Delphi was http://www.delphibasics.co.uk/. I still use it. It presents common methods in a nice way.
You might consider this post on beginner guides to Delphi. It has some good links included that may be rather simplistic for you, but can still take you a long way.
Marco Cantu (mentioned in several answers) also has a book series called "Mastering Delphi." It is a great (maybe only) top to bottom resource. Everything Delphi is in it. But the last edition is for 2005. Four versions of Delphi have been released since. There are a couple of update sheets available from Marco's website (D2006 was mostly a bug fix of 2005). And Marco also has the Handbook series, but that is aimed at people who already know Delphi and are looking for help on the newest improvements.
Personally, Delphi is my favorite language. I hope you enjoy it!
your name sounds german so you might wanne check these pages out
delphipraxis
it's not really a comparison for cpp and delphi/pascal but you'll find a lot of information
due to me being a new user i'm not able to post a second link. but search google for delphi forum..
The Free Pascal documentation is another great resource:
http://www.freepascal.org/docs.var
I've always been interested in writing and designing programming languages. Of course, it's pretty difficult to find an employer that will let you write a programming language as part of your job. So I'm looking for the "next best thing".
What fields of programming will let me get some experience solving some related problems? Or what kinds of employers are most likely to view all of my dinky little interpreters as relevant experience?
If your interest in language design is irrepressible, get a Ph.D. and make it your area of research. You can count on academia to support all manner of unprofitable activity.
None. The bulk of the professionals in that field do not design languages for a living, but retarget existing compilers to new (usually embedded) targets, or work on source2source conversion systems for legacy code, making a few language extensions in the process.
You should really ask yourself if you want this, because, besides from an extremely lucky shot, that is the realistic outlook of what you will do if you go into this industry.
Remember that the big public toolchain industry is not very profitable at the moment, and that maybe a good 100 languages are in largescale pulbic use and continually maintained, after 30 years of programming languages creation.
I know this is is very gloom, but I hope it sets you on the path to chuck the romantic, hobbyist view, and start researching how the real world in this field looks like.
Moreover, having done small hobby projects on your own is not really a pre. You need to show that you can work on large projects in a team, more than that you can create a small interpreter on your own. If you really want to pursue this, I'd recommend:
stay in school, and get a bachelor (preferably a master or PHD) in CS.
join some opensource team that works on a significant project in the field. gcc, but also the Java world, Tracemonkey (Mozilla), Mono etc. Verifiable experience in real world scenarios is very important.
I think the best way to get into this type of work would be to undertake an advanced degree with a specific focus on language design, compilers etc. It's going to be very tough for you to walk in off the street into a private company and start writing new language features otherwise.
You could also shoot a little higher and on your own, or with a small team, produce something that is much more than just a dinky little interpreter. Show your potential employer that you can produce something useful.
I have worked as an embedded programmer for the past ten years. Before that I wrote compilers (and assemblers, linkers, debuggers, etc.) for 20 years.
My co-workers joke that I turn every problem in to a parsing problem. And they're right. I've used techniques that are appropriate for language design many times during the course of my career.
Today, I play around with compiler stuff on the side: http://ellcc.org. It helps me scratch my language itch.
Actually, there is a fair bit of work going on with visual programming. It isn't exactly traditional programming language work as we know it but there is a need for it. For example, a lot of advanced data analysis tools rely on visual programming tools (Pentaho). You don't have to look too hard to find good practical uses of visual programming.
To get into visual programming languages, you will need to do an advanced degree with an advisor in the area. You will need to do some human computer interaction / interface work in addition to the programming language stuff.
An employer that has a rich "domain" (i.e. a complex industry) can benefit from a "domain specific language".
Will they realise this? Unlikely. They'll be too likely trapped in their deep domain (and entrenched legacy systems) to see that a targeted language could help unclog the mire.
But if you bury yourself in a complex industry for long enough to gain rich domain knowledge you may then be able to turn them with your own skunkwork DSL. Slim chance.
Stay in academia. If you want to develop a new language your chances of being paid to do so are vanishingly small. Newer languages tend to be expressions of a novel problem domain, and you only really encounter the chance to develop them where (a) novel problems are part of the scenery, and (b) no-one is troubled by the necessity to actually earn a living.
Please take your time over it, as well. Speaking as a jobbing developer, the last thing I need is another blasted language to learn :-)
In static analysis there is a lot to do, and the problems that come up are related to those that interest you.
Most currently popular languages came out of a geniune NEED to scratch a particular ITCH. Python came about because some non-C programmers NEEDed to customize inputs their C programs and libraries. Lua came out of the NEED to embed a scripting language in to C programs. Erlang was created to address the NEED of 99.9999999% uptime, hot code loading, and highly concurrent execution. Perl came out of the NEED to easily write programs that parsed text files.
So the very simple question any employer will be asking themselves, and you should ask yourself is. What NEED can I supply a solution to that doesn't exist. Hobby work very seldom shows that you are providing solutions to a NEED, most of the time it is showing that you like to re-invent the wheel for the sake of re-inventing the wheel.
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.
I'm currently learning to program, and I didn't take CS classes so I'm basically starting out on the bottom. I have been putting together code on and off for many years, but haven't really had a good understanding of essential concepts needed for enganging in bigger projects. Object-orientation is an obvious one, and I feel I'm beginning to understand some of the concepts there. Then there is a lot of buzz and methodology, such as MVC, UML, SCRUM, SOLID and so foth and so on.. I've looked at many of these but I'm always stumped as most explanations seem to require some understanding of other concepts.
I want to learn this stuff the "right" way, so where do I begin?
What are the overarching constructs I need to understand that enable me to understand all the underpinnings of software architecture/design/development?
What am I missing?
Are there constructs and concepts that can and should wait until I've cleared the foundation?
The SOLID principles are probably the most important.
From those you understand the motivation behind using a pattern such as MVC, why people think of persistence ignorance as important and so on. They are at the core of the majority of good practices.
Loose coupling, high cohesion.
And as for books, Code Complete covers almost everything at some level, at least.
Software development is a HUGE arena and you should be careful that you don't take on too much too quickly. Unless you're going to go in the direction of functional programming I'd suggest you start off by making sure you fully understand the concepts surrounding OO design and programming as this should be your foundation.
Once you understand that well you'll be able to understand design patterns a lot better and get a feeling for when to use them.
I'd suggest you try out a few languages till you find one you feel comfortable with, personally my favourite language is Ada which is a very pure OO language but in the business world I work in C# which still has a lot of issues but these are outweighed by the more vibrant job market.
I wouldn't worry too much about Scrum at this stage as you need to focus more on your dev skills before worrying about project management.
The most important thing is to work with as much code as possible, download lots of good reference solutions and work through the code till you understand it, and try and keep an eye on the development trends.
If its viable you may also want to considering attending some developer conferences too as these can be very inspirational.
Stay away from ACRONYMS (including those you've listed) and Methodologies(tm). At least in the beginning.
Read good books. Start with this one: Pragmatic Programmer. Learn algorithms and data structures, possibly from Introduction to algorithms by Cormen et al.
Write a lot of code. Practice is more important than anything else.
How to test software with unit tests. Being able to do that will solve 90% of all the other issue automatically since you can't test while they are around.
When you know how to test, you can start on advanced topics like design.
I'd recommend "Object Oriented Analysis and Design with Applications" by Grady Booch et al. The latest editoin has detailed explanation of concepts of OOAD including MVC, UML (which he invented), and discussions on how to manage the whole process of software development. The second part of the book exemplifies all this by developing 5 sample systems (with sometimes orthogonal aspects from the very core).
Another good one is of course Design Patterns by GoF which will give you an idea of loose coupling, ways to efficient encapsulation and reuse of code, etc
For what concerns the algorithmic part, take any book which is not bounded to a particular programming language. My favorite is Introduction to Algorithms by T. H. Cormen et al, it gets a bit theoretical at some points, but I especially like it when they are proving certain things and not just asking you to believe it.
When you are working with any modern general purpose language, it is probably a good idea to get a handle on patterns (MVC or Model-View-Controller is one). The book by the "gang of four" is a must read for this, or at least research a few and use it as a reference.
clicky
Refactoring is another concept that should be in your arsenal. The book by Martin Fowler on this subject is a very nice read and helps understand the aforementioned patterns better also a little explanation about UML is included.
Can't post more than one hyperlink so...
search on amazon for: Refactoring, Improving the design of existing code
When you want to communicate your designs UML (Unified Modelling Language) is the 'tool' of choice for many people. However UML is large and unwieldy but Martin Fowler (again) has managed to boil it down to the essentials.
search on amazon for: UML Distilled (make sure you get the most recent one)
SCRUM is one of many methods that is used to manage software development groups, I do not think there is much merit in learning that when you are just starting out or on your own. Especially not in detail.
Hope it helps...
PS: SOLID I haven't heard about yet, somebody else has to help you there.
You'd have a decent foundation if you surveyed basic Data Structures, Algorithms, and Algorithms Analysis.
I think that you should start coding real world problems to get a feel for problems in the programming domain.
Then you have a better background to understand why objects are important. Then, after managing objects, you will learn why patterns and OO principles are important.
Personally, I highly recommend the Agile Software Development, by Robert C Martin.
But it may be a long and tiresome read unless you have a feel for the problems being solved. I'm afraid that you may need 500-1000 hours of coding at the minimum before you get an appreciation that the problems being solved are real.
And it probably takes 7000+ hours before you develop an instinctive heart-felt pain from merely reading the problems, making this sort of book become the page-turner that it should be.
Regrettably, many of the sound practices that you should develop are only appreciated after having to live with your code over time. If you just do many excercises and abandon the code afterwards just "because it works", then you are missing out on the greatest pain of all. It is a luxury our industry does not have, and "technical debt" is a very very real and costly to those with large code bases.
I feel kinda silly answering my own question like this.. :) But one valuable resource I've found for learning to write code, is the Euler Project at http://www.projecteuler.net
It's basically a collection of mathmatical problems that you solve by writing your own solution to it. Once you've found the answer to a particular problem, you're allowed access to that problem's forum where different solutions are discussed. I was amazed at how much I was learning in a) solving a challenge, b) reading about other peoples approaches and c) how many programming languages there are out there! :)
The problems start out easy (you can tell by the number of people who's solved them) and progress to harder and harder problems.
Currently I'm working on problem #3, having solved the previous two... I recommend you start chippin' away at them, no matter your level!
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 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I am doing some research into common errors and poor assumptions made by junior (and perhaps senior) software engineers.
What was your longest-held assumption that was eventually corrected?
For example, I misunderstood that the size of an integer is not a standard and instead depends on the language and target. A bit embarrassing to state, but there it is.
Be frank; what firm belief did you have, and roughly how long did you maintain the assumption? It can be about an algorithm, a language, a programming concept, testing, or anything else about programming, programming languages, or computer science.
For a long time I assumed that everyone else had this super-mastery of all programming concepts (design patterns, the latest new language, computational complexity, lambda expressions, you name it).
Reading blogs, Stack Overflow and programming books always seemed to make me feel that I was behind the curve on the things that all programmers must just know intuitively.
I've realized over time that I'm effectively comparing my knowledge to the collective knowledge of many people, not a single individual and that is a pretty high bar for anyone. Most programmers in the real world have a cache of knowledge that is required to do their jobs and have more than a few areas that they are either weak or completely ignorant of.
That people knew what they wanted.
For the longest time I thought I would talk with people, they would describe a problem or workflow and I would put it into code and automate it. Turns out every time that happens, what they thought they wanted wasn't actually what they wanted.
Edit: I agree with most of the comments. This is not a technical answer and may not be what the questioner was looking for. It doesn't apply only to programming. I'm sure it's not my longest-held assumption either, but it was the most striking thing I've learned in the 10 short years I've been doing this. I'm sure it was pure naivete on my part but the way my brain is/was wired and the teaching and experiences I had prior to entering the business world led me to believe that I would be doing what I answered; that I would be able to use code and computers to fix people's problems.
I guess this answer is similar to Robin's about non-programmers understanding/caring about what I'm talking about. It's about learning the business as an agile, iterative, interactive process. It's about learning the difference between being a programming-code-monkey and being a software developer. It's about realizing that there is a differnce between the two and that to be really good in the field, it's not just syntax and typing speed.
Edit: This answer is now community-wiki to appease people upset at this answer giving me rep.
That I know where the performance problem is without profiling
That I should have only one exit point from a function/method.
That nonprogrammers understand what I'm talking about.
That bugfree software was possible.
That private member variables were private to the instance and not the class.
I thought that static typing was sitting very still at your keyboard.
That you can fully understand a problem before you start developing.
Smart People are Always Smarter than Me.
I can really beat myself up when I make mistakes and often get told off for self-deprecating. I used to look up in awe at a lot of developers and often assumed that since they knew more than me on X, they knew more than me.
As I have continued to gain experience and meet more people, I have started to realise that oftentimes, while they know more than me in a particular subject, they are not necessarily smarter than me/you.
Moral of the story: Never underestimate what you can bring to the table.
For the longest time I thought that Bad Programming was something that happened on the fringe.. that Doing Things Correctly was the norm. I'm not so naive these days.
I thought I should move towards abstracting as much as possible. I got hit in the head major with this, because of too much intertwined little bits of functionality.
Now I try keep things as simple and decoupled as possible. Refactoring to make something abstract is much easier than predicting how I need to abstract something.
Thus I moved from developing the framework that rules them all, to snippets of functionality that get the job done. Never looked back, except when I think about the time I naively thought I would be the one developing the next big thing.
That women find computer programmers sexy...
That the quality of software will lead to greater sales. Sometimes it does but not always.
That all languages are (mostly) created equal.
For a good long while I figured that the language of choice didn't really make much of a difference in the difficulty of the development process and the potential for project success. This is definitely not true.
Choosing the right language for the job is as important/critical as any other single project decision that is made.
That a large comment/code ratio is a good thing.
It took me a while to realize that code should be self documenting. Sure, a comment here and there is helpful if the code can't be made clearer or if there's an important reason why something is being done. But, in general, it's better to spend that comment time renaming variables. It's cleaner, clearer and the comments don't get "out of sync" with the code.
That programming is impossible.
Not kidding, I always thought that programming was some impossible thing to learn, and I always stayed away from it. And when I got near code, I could never understand it.
Then one day I just sat down and read some basic beginner tutorials, and worked my way from there. And today I work as a programmer and I love every minute of it.
To add, I don't think programming is easy, it's a challenge and I love learning more and there is nothing more fun than to solve some programming problem.
"On Error Resume Next" was some kind of error handling
That programming software requires a strong foundation in higher math.
For years before I started coding I was always told that to be a good programmer you had to be good at advanced algebra, geometry, calculus, trig, etc.
Ten years later and I have only once had to do anything that an eighth grader couldn't.
That optimizing == rewriting in assembly language.
When I first really understood assembly (coming from BASIC) it seemed that the only way to make code run faster was to rewrite it in assembly. Took quite a few years to realize that compilers can be very good at optimization and especially with CPUs with branch prediction etc they can probably do a better job than a human can do in a reasonable amount of time. Also that spending time on optimizing the algorithm is likely to give you a better win than spending time converting from a high to a low level language. Also that premature optimization is the root of all evil...
That the company executives care about the quality of the code.
That fewer lines is better.
I would say that storing the year element of a date as 2 digits was an assumption that afflicted an entire generation of developers. The money that was blown on Y2K was pretty horrific.
That anything other than insertion/bubble sort was quite simply dark magic.
That XML would be a truly interoperable and human readable data format.
That C++ was somehow intrinsically better than all other languages.
This I received from a friend a couple of years ahead of me in college. I kept it with me for an embarrassingly long time (I'm blushing right now). It was only after working with it for 2 years or so before I could see the cracks for what they were.
No one - and nothing - is perfect, there is always room for improvement.
I believed that creating programs would be exactly like what was taught in class...you sit down with a group of people, go over a problem, come up with a solution, etc. etc. Instead, the real world is "Here is my problem, I need it solved, go" and ten minutes later you get another, leaving you no real time to plan out your solution efficiently.
I thought mainstream design patterns were awesome, when they were introduced in a CS class. I had programmed about 8 years as hobby before that, and I really didn't have solid understanding of how to create good abstractions.
Design patterns felt like magic; you could do really neat stuff. Later I discovered functional programming (via Mozart/Oz, OCaml, later Scala, Haskell, and Clojure), and then I understood that many of the patterns were just boilerplate, or additional complexity, because the language wasn't expressive enough.
Of course there are almost always some kind of patterns, but they are in a higher level in expressive languages. Now I've been doing some professional coding in Java, and I really feel the pain when I have to use a convention such as visitor or command pattern, instead of pattern matching and higher order functions.
For the first few years I was programming I didn't catch on that 1 Kbyte is technically 1024 bytes, not 1000. I was always a little perplexed by the fact that the sizes of my data files seemed slightly off from what I expected them to be.
That condition checks like:
if (condition1 && condition2 && condition3)
are performed in an unspecified order...
That my programming would be faster and better if I performed it alone.