Ways to get started
Locked
Ways to get started
 
|
Hello all! I am a rubyist looking for more information on erlang, and I was hoping to find some resources... If you would be so kind as to let me know any that have helped you.
-- Cheers, Isaac
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
For the free approach check out www.learnyousomeerlang.com
I learned from Joe Armstrong's book Programming Erlang (Pragmatic Bookshelf) There's also Erlang Programming by Francesco Cesarini (O'Reilly). Most recently is Erlang and OTP in Action, by Martin Logan (Manning). This one puts special emphasis on using the OTP framework. I haven't read this one yet, but I've been to one of the ErlangCamps (which I gather follow a similar curriculum as the book) run by Martin, and can only imagine it's a great book. -- Jesse Gumm Sigma Star Systems 414.940.4866 On Jul 9, 2011 8:19 AM, Isaac Sanders <[hidden email]> wrote: Hello all! I am a rubyist looking for more information on erlang, and I was hoping to find some resources... If you would be so kind as to let me know any that have helped you. -- Cheers, Isaac
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
On Sat, Jul 9, 2011 at 7:20 PM, Jesse Gumm <[hidden email]> wrote: For the free approach check out www.learnyousomeerlang.com Apart from that excellent suggestion, I'd like to add few more and suggested order (what worked for me): 1. First read (gives you a sense of early achievement and keeps you motivated, since you make progress quite fast) -- 'Thinking in Erlang'.
2. A kind of style guide http://www.erlang.se/doc/programming_rules.shtml 3. Joe's book (by this time, I could make progress, much faster)
4. 'Erlang in Practise' video tutorials (paid, but very economical). Much easier to follow, once you've gone thru step 1/2/3, and you can very quickly get a feel or real-life application development. While there are books which do the same, but as they say, a picture (or a video) is worth several thousand words. Coming from the Ruby (& esply so if RoR) world, you'd spoilt with choices / availability of ample such videos. While there are quite a few video tutorials for Erlang, only few are hard-core programming centric, where they show you creation of something interesting.
-- regards, Banibrata http://www.linkedin.com/in/bdutta http://twitter.com/edgeliving _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by Isaac Sanders
On Sat, Jul 9, 2011 at 7:18 AM, Isaac Sanders <[hidden email]> wrote:
> Hello all! I am a rubyist looking for more information on erlang, and I was > hoping to find some resources... If you would be so kind as to let me know > any that have helped you. In addition to the books and the online resources mentioned... I find it helps to pick a project that you'd be comfortable solving in another language, then tackle it in Erlang. Solve mini problems as you go. Ask questions here. I find http://erldocs.com/ helpful as a reference. Garrett P.S. Come to think of it, I don't know if http://www.erlang.org/doc.html was mentioned. None of the books are a substitute for that. _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
The biggest problem that I am running into is that my Unix sys admin experience 10+ years ago doesn't help much. Using Git, Rebar, and even make is a steep hill for me to travel. I've been through numerous tutorials and documentation and there is this massive body of knowledge that I just don't have, or these tutorials just assume you know.
I get Erlang. That's the easy part. It's just the underlying development structure and environment that gets in my way.
How do I get Erlang from github? Where do I put it once I get it? How does rebar fit into this picture? What does a development cycle look like using these tools?
Really Really basic stuff.
--Peter
From: "Garrett Smith" <[hidden email]> _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
|
On Mon, Jul 11, 2011 at 11:41 AM, <[hidden email]> wrote:
> I get Erlang. That's the easy part. It's just the underlying development > structure and environment that gets in my way. I hit the same issue. I went so far as to pick up Emacs. I have to say, I'm quite happy with the result, but that's a pretty big pill to swallow when you want to simply add Erlang to your repertoire. And you don't *have* to use Emacs. But for me it was the path of least resistance. I'd be curious to know what editor/IDE/toolset people use other than Emacs. Catch is, you have to be overall happy with it :) > Is there a real 101 that can give me a leg up? Really basic questions like: > > How do I get Erlang from github? Where do I put it once I get it? Use a system package (e.g. aptitude, yum, pacman) or a mainstream installer. I wouldn't mess with compiling from scratch, much less getting source from github. > How does rebar fit into this picture? Rebar is emerging as the de facto standard for building Erlang projects. Most projects that use rebar also provide a Makefile, but I wouldn't worry about make files in your case. There are a few good "getting started" guides with rebar. I'd start with those. > What does a development cycle look like using these tools? The most basic work flow is to use an editor to modify your Erlang source files and then run your compilation ("rebar compile") in a separate shell. It gets more streamlined from there depending on the toolset. Garrett _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
|
In reply to this post by pmacgown
On Mon, Jul 11, 2011 at 11:11 PM, <[hidden email]> wrote:
Peter, What you describe, I think, is quite typical of people who are picking up a new language, and if they've not been programming very actively, lately. I am in that stage, and have gone thru similar struggles. However, in the end, one need to master each of those tools, to learn Erlang. In fact, I think it is pointless to master rebar and git, if you are just a beginner. What might suffice (to tide over the curve), is to know a very small handful of tool command vocabulary. For example -- 1) cloning a git repository 2) setting up a rebar project 3) compiling/building project with rebar rest can wait. I've fallen into the Emacs honey pot (every one, in every video turtorial/presentation on Erlang, seems to be using Emacs), and struggled to learn just enough, although, now I realize that with Erlide (Emace based) or even with vi + command-line bash aliases, I am as productive.
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by Garrett Smith-5
On Jul 11, 2011, at 2:13 PM, Garrett Smith wrote:
CLI for building and everything else.
Distro packages tend to be outdated, Mac packagers as well. Mihai_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
I'm old school - you don't need any fancy tools. Just a text
edit and an erlang shell. Open your text editor: Type in the following program. -module(hello). -compile(export_all). start() -> "hello world". store it in a file called hello.erl Start and erlang shell. It will say ">" Type in two commands: > c(hello). > hello:start(). The first command compiles the program. The second evaluates the command hello:start() Thats all it takes - typing three lines of code into a file with a text editor - then typing two lines into the shell. That's all it takes. 95% of all the fun can be achieved with a simple text editor and the erlang shell. That's how most of the erlang system was implemented. The erlang shell can be installed in zillions of ways - compile the sources or apt-get install it (or whatever) Forget about git/IDEs/rebar etc. Use this approach for all languages. IDEs and build tools are the single biggest obstacle I know of to getting started. Me I use - a shell - makefiles - emacs for all know programming languages under the sun. 98% of all the fun can be had with the compiler alone - all the rest is hype. Forget about the tools - Tools like rebar etc are under to automate something but if you don't know what it is that you are automating and if the tool doesn't work you will just end up being incredible confused. Then buy a decent book and type in the programs by hand. One at a time thinking as you go. After 30 years you will get the hang of this and be a good programmer. Tools are no substitute for typing in small programs and understanding exactly how they work. This is true for all programming language. Programming is an art form, there is no easy way. Like playing the violin - is there an easy way of playing the violin other than by practising for thousands of hours? I think not. Start with one liners in the shell, start the shell: type > A = 1 then > A = 2 ask what happens and why. There is no quick way to learn programming - no tool will help. Your brain is a zillion times better than the best IDE. programs form in you brain not in an IDE. But then I'm old school. Have fun - if it's not fun it is pointless - don't fight the tools all you need is a text editor and the erlang shell to start with. /Joe On Mon, Jul 11, 2011 at 10:27 PM, Mihai Balea <[hidden email]> wrote: > > On Jul 11, 2011, at 2:13 PM, Garrett Smith wrote: > > I'd be curious to know what editor/IDE/toolset people use other than > Emacs. Catch is, you have to be overall happy with it :) > > I use Text Mate, it's fast and there's a decent Erlang bundle available. > CLI for building and everything else. > > > Use a system package (e.g. aptitude, yum, pacman) or a mainstream > installer. I wouldn't mess with compiling from scratch, much less > getting source from github. > > I always build from the official sources. It's quite easy, basically just > configure, make, sudo make install > Distro packages tend to be outdated, Mac packagers as well. > > Mihai > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions > > erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by Garrett Smith-5
> I'd be curious to know what editor/IDE/toolset people use other than
> Emacs. Catch is, you have to be overall happy with it :) I have to say that I enjoy erlide in eclipse. It is nice when I'm doing extensive application development. I particularly like the compile/load on save functionality it provides. I have had to play with different versions to get the performance I wanted, but things have gotten better recently. I still log to external files and tail the logs to watch for supervisor reports. I completely developed Surrogate (https://github.com/skruger/Surrogate) using ErlIDE and it has been a very enjoyable experience. Shaun ----- Original Message ----- > From: "Garrett Smith" <[hidden email]> > To: [hidden email] > Cc: [hidden email] > Sent: Monday, July 11, 2011 12:13:30 PM > Subject: Re: [erlang-questions] Ways to get started > > On Mon, Jul 11, 2011 at 11:41 AM, <[hidden email]> wrote: > > I get Erlang. That's the easy part. It's just the underlying > > development > > structure and environment that gets in my way. > > I hit the same issue. I went so far as to pick up Emacs. I have to > say, I'm quite happy with the result, but that's a pretty big pill to > swallow when you want to simply add Erlang to your repertoire. > > And you don't *have* to use Emacs. But for me it was the path of > least > resistance. > > I'd be curious to know what editor/IDE/toolset people use other than > Emacs. Catch is, you have to be overall happy with it :) > > > Is there a real 101 that can give me a leg up? Really basic > > questions like: > > > > How do I get Erlang from github? Where do I put it once I get it? > > Use a system package (e.g. aptitude, yum, pacman) or a mainstream > installer. I wouldn't mess with compiling from scratch, much less > getting source from github. > > > How does rebar fit into this picture? > > Rebar is emerging as the de facto standard for building Erlang > projects. Most projects that use rebar also provide a Makefile, but I > wouldn't worry about make files in your case. There are a few good > "getting started" guides with rebar. I'd start with those. > > > What does a development cycle look like using these tools? > > The most basic work flow is to use an editor to modify your Erlang > source files and then run your compilation ("rebar compile") in a > separate shell. It gets more streamlined from there depending on the > toolset. > > Garrett > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions > erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
|
In reply to this post by Garrett Smith-5
I'm a Gnu Screen (byobu version) split vertically and vim guy.
I'm perfectly happy with my setup. It's simple, portable and gets the job done. -Jesse > I'd be curious to know what editor/IDE/toolset people use other than > Emacs. Catch is, you have to be overall happy with it :) Garrett _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by Joe Armstrong-2
I'd like to add to this and say that when I started out with erlang, Makefiles were one of the hurdles I faced. Having never written a makefile before it seemed an unnecessarily cryptic way to get files compiled. Of course, there were plenty of examples out there and I was able to _mostly_ get it to do what I wanted.
But like Joe describes below, it doesn't need to be like that. My epiphany came the day that I realized what my makefile was doing: stepping through .erl files, and using erlc to create .beam files. No magic. With that realization it took me 5 minutes and a few lines of php to do _exactly_ what I wanted and never have to bend my head around a makefile again. Those who have spent years writing makefiles might find this a little stupid :P But to me it removed the hurdle and made it easy to get stuff done, which is why we write code, right? :) It seems that complicated tools and processes can often hide the underlying simplicity. Of course you might get to a point where you need those tools, but for a beginner the most important thing is to dispel the illusion and see how simple it actually can be. Josh. On 12/07/2011, at 6:49 AM, Joe Armstrong wrote: > I'm old school - you don't need any fancy tools. Just a text > edit and an erlang shell. > > Open your text editor: > > Type in the following program. > > -module(hello). > -compile(export_all). > start() -> "hello world". > > store it in a file called hello.erl > > Start and erlang shell. It will say ">" > Type in two commands: > >> c(hello). >> hello:start(). > > The first command compiles the program. The second evaluates > the command hello:start() > > Thats all it takes - typing three lines of code into a file > with a text editor - then typing two lines into the shell. > > That's all it takes. 95% of all the fun can be achieved with a simple > text editor and the erlang shell. That's how most of the erlang system > was implemented. > > The erlang shell can be installed in zillions of ways - compile the > sources or apt-get install it (or whatever) > > Forget about git/IDEs/rebar etc. > > Use this approach for all languages. > > IDEs and build tools are the single biggest obstacle I know > of to getting started. > > Me I use > > - a shell > - makefiles > - emacs > > for all know programming languages under the sun. > > 98% of all the fun can be had with the compiler alone - all the rest > is hype. > > Forget about the tools - > > Tools like rebar etc are under to automate something but if you don't > know what it is that you are automating and if the tool doesn't work > you will just end up being incredible confused. > > Then buy a decent book and type in the programs by hand. > One at a time thinking as you go. > > After 30 years you will get the hang of this and be a good programmer. > > Tools are no substitute for typing in small programs and > understanding exactly how they work. This is true for all programming > language. Programming is an art form, there is no easy way. > Like playing the violin - is there an easy way of playing the violin other > than by practising for thousands of hours? I think not. > > Start with one liners in the shell, start the shell: > > type >> A = 1 > > then > >> A = 2 > > ask what happens and why. > > There is no quick way to learn programming - no tool will help. > > Your brain is a zillion times better than the best IDE. programs > form in you brain not in an IDE. > > But then I'm old school. > > Have fun - if it's not fun it is pointless - don't fight the tools > all you need is a text editor and the erlang shell to start with. > > /Joe > > > > > > > > > > On Mon, Jul 11, 2011 at 10:27 PM, Mihai Balea <[hidden email]> wrote: >> >> On Jul 11, 2011, at 2:13 PM, Garrett Smith wrote: >> >> I'd be curious to know what editor/IDE/toolset people use other than >> Emacs. Catch is, you have to be overall happy with it :) >> >> I use Text Mate, it's fast and there's a decent Erlang bundle available. >> CLI for building and everything else. >> >> >> Use a system package (e.g. aptitude, yum, pacman) or a mainstream >> installer. I wouldn't mess with compiling from scratch, much less >> getting source from github. >> >> I always build from the official sources. It's quite easy, basically just >> configure, make, sudo make install >> Distro packages tend to be outdated, Mac packagers as well. >> >> Mihai >> _______________________________________________ >> erlang-questions mailing list >> [hidden email] >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
In reply to this post by Garrett Smith-5
On Mon, Jul 11, 2011 at 11:13 AM, Garrett Smith <[hidden email]> wrote:
> I'd be curious to know what editor/IDE/toolset people use other than > Emacs. Catch is, you have to be overall happy with it :) joe, with a syntax highlighting file I made myself. Looks like this: https://lh3.googleusercontent.com/-oCPlbMVnPe8/Te7Puuzu5jI/AAAAAAAABnE/w-56jRE_tSo/s800/erlsyntaxinjoe.PNG (pay no heed to the ugly random bits of code, this was early in my experimenting) That, plus a bash shell in another window, and an instance of werl. _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by pmacgown
Peter:
The thing is, for any significant project, you *will* need a development tool chain either to reduce complexity, automate tasks, or simply because someone else is using a tool in their project which you'd like to build. Here, I use the term "tool chain" loosely to describe all tools that you *could* use to develop software, not in the strict compiler tool chain sense. These typically include (not an exhaustive list): * Source Control: Git, Mercurial, Subversion, ... * Build Managment/Automation: Rebar, GNU Make, Buildout, Rake, CMake, SCons, ... * Text Editor: vim, emacs, textmate, ... * Preprocessors/Compilers: erlc, gcc, javac * Virtual Machine/Runtime: erl vm, CRuby, CPython, java vm The last three are all you need to use Erlang. But the first two are critical for any serious project. Maybe what you are looking for is for someone to guide you through an example development environment, complete with using a tool from each of the categories above. However, it's rarely that there is a default toolset for any language and developers/engineers will use what they like (and will change often). I use Mercurial/Git, Make, Vim among other tools. I suggest you look up the basic use of each tool separately. Sure it takes time, but you don't have to master each to be productive. For example, I don't have to understand the three different types of Make variable assignments to compile a package by typing: ./configure; make; sudo make install. Cheers, -signed(ahmed). On 7/11/11 1:41 PM, [hidden email] wrote:
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by Joe Armstrong-2
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
|
On Tue, Jul 12, 2011 at 3:05 PM, Avinash Dhumane <[hidden email]> wrote:
Tricky - when I had company we always sent two people to a sales meeting. The sales guy + a programmer. The sales guy does the "pitch" and the programmer answers the technical questions. It's not good to send a sales guy into a group of programmers - they get found-out after a few minutes. It's not good to send a programmer to a meeting. programmers don't bother with follow-up calls and "what do we do next" type stuff - on a good day they will try to solve all the customers problems in the sales meeting and be done with it. One of the great success factors of Cisco was they always sent engineers to sales meetings.
If I were in the room when you did this I would ask what all the abbreviations stood for and ask how Paxos worked. I have a vague idea how paxos works and would be keen to learn more. This is why you need your technical guy in the sales group.
No - it's difficult - if sales were easy and you could just follow some magic formula then I guess all salesmen would be stinking rich - since they aren't then it must be tricky. Jane Walerud a blutail co-founder said that "it was all about the relationship" - feelings warm fuzzy stuff that programmers don't understand - she was probably right. Most of the programmers I know are the worse salesmen on the planet - they don't want to buy software because they'd rather write it themselves and mostly they want to give away what they have done not sell it. Cheers - and sorry I can't help more /Joe
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
In reply to this post by Joe Armstrong-2
On Mon, Jul 11, 2011 at 22:49, Joe Armstrong <[hidden email]> wrote:
> > Your brain is a zillion times better than the best IDE. programs > form in you brain not in an IDE. > Very true. I often sit pondering on a problem. Ride the bike and ponder on the problem. Play computer games while the brain ponders on the problem unconsciously. Go see Rich Hickey's "Hammock Driven Development", http://blip.tv/clojure/hammock-driven-development-4475586 Then, as soon as the solution to the problem forms in the brain, it is often a quick task of 10-15 minutes to write the 50-100 lines of code which solves it. The only thing that makes the old guys seem to darn effective at producing code is that they cheat. They have done it before and they just have to alter small things to make it right. And they know what code not to write (Code lines are spent, not produced - http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html ). The hard part of programming is to get the right solution. The tools you use matter almost nothing as they usually don't help you get the right solution. The point in addition is focus. If you have focus on getting a git repo on github, focus on configuring and installing rebar, focus on getting an IDE - then you are not spending time on understanding Erlang. A virtue I learned as a programmer is to keep focus on one thing at a time. Whenever you are on a task and another thing you should do pops up, write it down somewhere and ignore it for now. Our brains, when we work, are not multi-core machines. You can always go back and add a build system when the code you are writing gets too big to handle as separate compiles. You can always add Version Control later. Programs are like seeds. They are planted and then they grow under nurture and care. Don't plan for the Giant Sequoia when all you have is a sapling. -- J. _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
|
In reply to this post by Avinash Dhumane
On Tue, Jul 12, 2011 at 7:05 AM, Avinash Dhumane <[hidden email]> wrote:
> > How would a Sales person get himself started? No, I am not a programmer. But, I > am tasked to sell an abstract form that embodies Erlang/OTP as its DNA. And, my > prospects are the CXOs in the enterprise application software space. Please bear > with me a little bit so that I can articulate my difficulties. I've sold software and developer services and I'm also a programmer. IMO selling packaged software is a completely different ball of wax from services. I'm not sure what an "abstract form" is. If what you have is a product, I think leading with the underlying language is a mistake. Surely there's some business value to focus on. Regarding Erlang/OTP you might just keep it high level: "You guys heard of five nines? How about nine nines!" and reference the host of Erlang success stories. That's a truth stretching exercise that people on this list will wince at, but since you're the "sales guy" you get a bit of a pass. If you get drilled on the details, as Joe mentioned, punt over to your sales support engineer. If she can't be there in person, have her on speaker phone. If you're selling services, I think you're in difficult waters. Unless you have a deep track record in some vertical or some leveragable asset, pitching an architecture, at least in my experience, will be all up hill. If you have that track record or asset, lead with its customer value. The technical underpinnings are generally slated for side discussions. Best of luck -- I'd love to see Erlang make better in roads in the CXO circles! Garrett _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
|
In reply to this post by Jesper Louis Andersen-2
On Tue, Jul 12, 2011 at 4:58 PM, Jesper Louis Andersen
<[hidden email]> wrote: > On Mon, Jul 11, 2011 at 22:49, Joe Armstrong <[hidden email]> wrote: >> >> Your brain is a zillion times better than the best IDE. programs >> form in you brain not in an IDE. >> > > Very true. I often sit pondering on a problem. Ride the bike and > ponder on the problem. Play computer games while the brain ponders on > the problem unconsciously. Go see Rich Hickey's "Hammock Driven > Development", > > http://blip.tv/clojure/hammock-driven-development-4475586 > > Then, as soon as the solution to the problem forms in the brain, it is > often a quick task of 10-15 minutes to write the 50-100 lines of code > which solves it. The only thing that makes the old guys seem to darn > effective at producing code is that they cheat. They have done it > before and they just have to alter small things to make it right. And > they know what code not to write (Code lines are spent, not produced - > http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html > ). > > The hard part of programming is to get the right solution. The tools > you use matter almost nothing as they usually don't help you get the > right solution. Yes - at a rough guess 90% of time = understanding the problem 10% coding the final version (in the 90% I'll write lots of code to throw away - no point in having a revision control system for this bit) - I don't want to keep it As for the gits etc. I just learn half a dozen commands and stick to them Time spent of fixing your tools is time not spent on thinking about the problem. The most efficient code is the code that is never written - I throw away (say) 50% of all the code I write. When I was a beginner I would throw away 75% my goal would be to throw away 0% that would mean I had though long and hard enough before writing the code to only write good that was good enough to keep. (These are only rough figures - I guess I reckon on writing things two or three times, years ago was up at six times, Knuth says everything should be rewritten seven times) > > The point in addition is focus. If you have focus on getting a git > repo on github, focus on configuring and installing rebar, focus on > getting an IDE - then you are not spending time on understanding > Erlang. Yup - also I cannot really understand why people want to learn specialist tools for the development of things in language X if such tools cannot be used with language Y. rebar is great if you understand what it is abstracting, otherwise useless. I use emacs, shell scripts, make and xterm for *everything*. I use this for writing erlang,c,java,javascript,TCL,assembler,bash scripts, makefiles, html, css, I also make sure that emacs, make etc. work the same way on OS-X,ubuntu and windows. In the early 80's I wrote about 150K lines of FORTRAN with a line editor (full screen editors had not been invented) all the files were in one directory (the OS didn't have hierarchal directories) and there was a ten character limit on file names. There was no revision control system - 10 programmers worked on the same system. I don't actually believe that modern tools would have made me significantly more efficient. To circumvent the limitations we invented ad hock versions of email, revision control, etc. Not fancy things but they got the job done. As today most of my time in the 80's was spent understanding the problem - since this takes 90% of the time providing tool support in the other 10% is not likely to help productivty. Programming languages hit directly at the 90% because they are tools for thought - GIT etc does not help me think. Prolog/Haskell/Erlang provide ways of thought that are superior to C/C++/Java. Give me better ways of thinking with bad tools support rather than bad ways of thinking with good tool support. I still use printf debugging in all languages. I think that things like debugging cause compensation mechanisms to come into place - if language X is very difficult to debug then you think a little harder before writing the program. Also true of fancy revision control systems - if I've got one fine, If not I'll compensate by thinking a little more. Most programming takes place in my head - tapping the stuff in is the last part of a long and mostly invisible process. There should be a name for this development process. Zen development - no tools - just your brain - all we are doing in making pleasing patterns of zeros and ones that follow the way of programming. If we follow the way the programs will please us. /Joe > A virtue I learned as a programmer is to keep focus on one > thing at a time. Whenever you are on a task and another thing you > should do pops up, write it down somewhere and ignore it for now. Our > brains, when we work, are not multi-core machines. > > You can always go back and add a build system when the code you are > writing gets too big to handle as separate compiles. You can always > add Version Control later. Programs are like seeds. They are planted > and then they grow under nurture and care. Don't plan for the Giant > Sequoia when all you have is a sapling. > > -- > J. > erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: Ways to get started
|
On 07/12/2011 10:01 PM, Joe Armstrong wrote:
> 90% of time = understanding the problem > 10% coding the final version > > (in the 90% I'll write lots of code to throw away - no point in having > a revision control system for this bit) - I don't want to keep it This part is very important. That's how good code is written. It is essential however to write code in the 90% of time, you can't just "think" about it, you have to try an implementation, learn from the mistakes you made, try another, and so on, until you find the best one. First time you might have to rewrite it all, then as you get closer to your goal you get less and less to rewrite. Of course most people with deadlines just stick with the first version of their code. But that's a mistake as it'll leave bugs that you'll have to fix, and the bad code you wrote for the first deadline is going to make the next deadlines harder to get. So you write code that becomes worse as time goes on and the project becomes a mess. If you can't use Joe's method when starting a project and still meet the deadline, then the planning was wrong and you simply needed more time. Don't kill your projects at birth just to meet some arbitrary time requirement. Because I'm sure you all know that estimating development time is far from a science. > Zen development - no tools - just your brain - all we are doing > in making pleasing patterns of zeros and ones that follow the way > of programming. If we follow the way the programs will please us. "Zen" is kind of overused. But that sums it up nicely. Note though that while good tools aren't necessary for development, they are important for maintenance, bug fixing and even bug detection. Bisecting for example allows to find causes of regressions much more efficiently than printf. Tests, dialyzer, git and all the other tools become important only when you are done iterating over your program's architecture. But even then they aren't as important as the code itself. -- Loïc Hoguin Dev:Extend _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
| Powered by Nabble | Edit this page |