Planet Erlang http://www.planeterlang.org/en/planet/planet en Planet Erlang Copyright 2012 2012-05-16T17:31:31+00:00 Erlang Software Engineer / Senior Developer , Stockholm, London, Krakow, East and West coast USA http://www.planeterlang.org/en/planet/article/Erlang_Software_Engineer_Senior_Developer_Stockholm_London_Krakow_East_and_/ http://www.planeterlang.org/en/planet/article/Erlang_Software_Engineer_Senior_Developer_Stockholm_London_Krakow_East_and_/ Role Description:

With our portfolio of customer facing projects and consultancy assignments increasing in all of our offices, we are looking for talented individuals to join our young and dynamic team. We are looking for both experienced and junior developers with knowledge of functional programming languages such as Erlang, Clojure, Haskell, Scala and the imperative languages like C, Java and Objective-C.

The right candidates will join small teams of highly skilled systems engineers developing software using Erlang/OTP. You will gain valuable experience in exciting state-of-the-art systems within the Financial Services, Automotive, Telecom and Gaming sectors. As our clients are spread on six continents, you will be required to be flexible about travel to customer locations for short periods when required.

 Responsibilities:

  • With experience of real time or embedded software and associated hardware, this role would be responsible for the design and programming of related operating software.
  • Liaise with Electronic Design Engineers to ensure that the functionality meets specifications.
  • May be responsible for other Software Engineers within a project team.
  • Design, code, test and support of Erlang and related software, including some research.
  • Develop solutions using distributed concurrent programming, software packaging and release
    • Write and test code in Erlang and occasionally in other languages such as C, Java, Clojure, Haskell, Scala & Objective-C .
    • Experienced programmers will be expected to mentor and coach junior staff.

Minimum Education, Certification, Training:

A Degree or Masters in Computer Science, or an Erlang Foundation level certification.

 Skills and experience required:

Essential

  • Experienced in the use of the Erlang Open Telecoms Platform for the delivery of complex systems
  • Must have demonstrable experience of designing and delivering multiple projects in at least one industry sector
  • About three years demonstrable software development and implementation experience
  • Demonstrable knowledge of Erlang programming which will be tested.
  • Experience with Linux, OS X and Solaris operating systems
  • Good verbal and written communication in English
  • Good customer facing and presentation skills.

Desirable

  • Experience with languages such as C and Java
    • Knowledge of Distributed Computing, in a multicore environment
    • Track record of being able to achieve project milestones and complete tasks.
    • Experience of implementation of soft real time servers
    • Experience with interconnection protocols (HTTP, XMPP, SMPP, ...)
    • Experience with Agile Methods, including Test Driven Development
    • Problem-solving and thinking laterally as part of a team to meet the needs of the project.
    • Ability to plan and estimate work.

Eligibility:

The right candidate will work in a rapidly expanding company and community, receive a competitive salary with full benefits.

Equal opportunities:

Erlang Solutions is an equal opportunities employer and positively encourages applications from suitably qualified and eligible candidates regardless of sex, race, disability, age, sexual orientation, gender reassignment, religion or belief, marital status, or pregnancy and maternity.

]]> Companies, Erlang Solutions 2012-05-16T17:31:31+00:00 Senior Erlang Software Engineer / Architect, Stockholm, London, Krakow, East and West coast USA http://www.planeterlang.org/en/planet/article/Senior_Erlang_Software_Engineer_Architect_Stockholm_London_Krakow_East_and_/ http://www.planeterlang.org/en/planet/article/Senior_Erlang_Software_Engineer_Architect_Stockholm_London_Krakow_East_and_/ Role Description:

With our portfolio of customer facing projects and consultancy assignments increasing in all of our offices, we are looking for talented individuals to join our young and dynamic team. We are looking for both experienced and junior developers with knowledge of functional programming languages such as Erlang, Clojure, Haskell, Scala and the imperative languages like C, Java and Objective-C.

 The right candidates will join small teams of highly skilled systems engineers developing software using Erlang/OTP. You will gain valuable experience in exciting state-of-the-art systems within the Financial Services, Automotive, Telecom and Gaming sectors. As our clients are spread on six continents, you will be required to be flexible about travel to customer locations for short periods when required.

 Responsibilities:

  • With an in depth knowledge of real time or embedded software and associated hardware, this role would be responsible for the architecture design and programming of related operating software.
  • Liaise with Electronic Design Engineers to ensure that the functionality meets specifications.
  • May be responsible for other Software Engineers within a project team.
  • Design, code, test and support of Erlang and related software, including some research.
  • Develop solutions using distributed concurrent programming, software packaging and release
    • Write and test code in Erlang and occasionally in other languages such as C, Java, Clojure, Haskell, Scala & Objective-C .
    • Experienced programmers will be expected to mentor and coach junior staff.

Minimum Education, Certification, Training:

A Degree or Masters in Computer Science, or an Erlang Foundation level certification.

 Skills and experience required:

Essential

  • Experienced in the use of the Erlang Open Telecoms Platform for the delivery of complex systems.
  • Must have demonstrable experience of architecture design and delivering multiple large projects in different industry sectors.
  • More than five years demonstrable software development and implementation experience
  • Experience with Linux, OS X and Solaris operating systems
  • Good verbal and written communication in English
  • Good customer facing and presentation skills.

Desirable

  • Experience with languages such as C and Java
    • Knowledge of Distributed Computing, in a multicore environment
    • Track record of being able to achieve project milestones and complete tasks.
    • Experience of implementation of soft real time servers
    • Experience with interconnection protocols (HTTP, XMPP, SMPP, ...)
    • Experience with Agile Methods, including Test Driven Development
    • Problem-solving and thinking laterally as part of a team to meet the needs of the project.
    • Ability to plan and estimate work.

 Eligibility:

The right candidate will work in a rapidly expanding company and community, receive a competitive salary with full benefits.

Equal opportunities:

Erlang Solutions is an equal opportunities employer and positively encourages applications from suitably qualified and eligible candidates regardless of sex, race, disability, age, sexual orientation, gender reassignment, religion or belief, marital status, or pregnancy and maternity.

]]> Companies, Erlang Solutions 2012-05-16T17:31:29+00:00 Getting Flymake and Rebar to Play Nice http://www.planeterlang.org/en/planet/article/Getting_Flymake_and_Rebar_to_Play_Nice/ http://www.planeterlang.org/en/planet/article/Getting_Flymake_and_Rebar_to_Play_Nice/ Eric B Merritt A

]]> Blogs, Erlware 2012-05-15T22:39:32+00:00 25 May 2012: Poznan Erlang User Group Event http://www.planeterlang.org/en/planet/article/25_May_2012_Poznan_Erlang_User_Group_Event/ http://www.planeterlang.org/en/planet/article/25_May_2012_Poznan_Erlang_User_Group_Event/ Further Details

Date : 11 May 2012

Time : 18:00 -19:00

Limit: 50 people

Location: ZOO Coworking Space, ul. Zwierzyniecka 20, Poznań (Poland)
II floor

You can register here.



The Programme:

18:00 “Erlang Use Cases” Michał Ślaski

The plan of the presentation is TBC

Bio: Michal Slaski (Senior Erlang consultant and software architect   Erlang Solutions Ltd,  Speaker,  A Senior Software Consultant at Erlang   Solutions)
Michal Slaski started programming in Erlang at the AGH - University of   Science and Technology in Krakow, Poland, when working on his Masters   prototyping massively multiplayer online games. After graduating, he   joined Erlang Solutions on key projects around the world. He is   currently heading Erlang Solutions’ new Krakow office in Poland, keeping   the Erlang flag up high.

18:30 “Riak in the hosting system of tablica.pl” Rafał Skrzypek 

The plan of the presentation:
1. Who are we? What we do? (aside from the tablica.pl project)
2. Brief overview of the technologies we use.
3. Storing images in our services - what solutions did we use, what problems did we encounter?
4. What is Riak and why did we decided to use it?
5. What were the original problems Riak made us face?
6. What is our current configuration and what kind of data do we store?
7. What are our plans for the future use of Riak?

Bio: I am the IT administrator responsible for implementation and maintenance
of the infrastructure for services based on tablica.pl framework.


Everyone is welcome. Come along learn, listen, debate, shape, join in, share experiences, exchange ideas and network.

]]> Companies, Erlang Solutions 2012-05-15T16:31:25+00:00 14 May 2012: Supporting ComputerAid through Pedal Power to Brussels http://www.planeterlang.org/en/planet/article/14_May_2012_Supporting_ComputerAid_through_Pedal_Power_to_Brussels/ http://www.planeterlang.org/en/planet/article/14_May_2012_Supporting_ComputerAid_through_Pedal_Power_to_Brussels/ Erlang Solutions’ Steve Roberts will be embarking on a gruelling 3 day bike ride from London to Brussels to raise money for his chosen charity, ComputerAid International.

ComputerAid take unwanted computers, refurbish them and give them to African non profit organisations such as schools and hospitals. Their work doesnt just stop there. They ensure that the organisations know how use the technology they are being given so they can learn for example how to use technology to improve crop growing.
 
The endurance session starts at 7.15am on Friday 18th May reaching Calais late in the evening on day 1.  Day 2 is another 7.15am start reaching the beautiful town on Bruges late in the afternoon.  Sunday is a lay-in with a start time of 7.45, arriving Brussels finish line, late afternoon.

Eurostar London to Brussels: 1 hour 57 minutes

Pedal power to Brussels: 3 days

 

Click here to sponsor Steve!

 

 

 

 

]]> Companies, Erlang Solutions 2012-05-14T17:30:14+00:00 10 May 2012: Erlang Embedded with Raspberry Pi Video Tutorials http://www.planeterlang.org/en/planet/article/10_May_2012_Erlang_Embedded_with_Raspberry_Pi_Video_Tutorials/ http://www.planeterlang.org/en/planet/article/10_May_2012_Erlang_Embedded_with_Raspberry_Pi_Video_Tutorials/ Sweet things are better   shared, so we are pleased to announce our series of video tutorials on   Erlang Embedded with Raspberry Pi. With two videos already released,  popularity is growing by the minute. Follow us on Twitter to get regular updates, give Omer suggestions and see what he will be coming up with next.

What exactly is Raspberry Pi and why should we pay attention to it? It   is essentially a credit-card sized computer that plugs into your TV.  The design is based on Broadcom BCM2835 SoC, which includes a 700MHz ARM11 processor, VideoCore IV GPU and 256 megabytes of RAM. It is a pretty powerful platform as far as embedded systems go, and with strong demand for these boards it seems like the R-Pi Foundation was caught off-guard;  suppliers are now quoting July delivery dates for new orders.

 

]]> Companies, Erlang Solutions 2012-05-10T17:01:15+00:00 10 May 2012:  Scalability of the Erlang VM and FreeBSD (reaching 2.5M+ concurrent connections/box) http://www.planeterlang.org/en/planet/article/10_May_2012_Scalability_of_the_Erlang_VM_and_FreeBSD_reaching_2.5M_concurre/ http://www.planeterlang.org/en/planet/article/10_May_2012_Scalability_of_the_Erlang_VM_and_FreeBSD_reaching_2.5M_concurre/
They reduced the number of contentions in BEAM and tweaked OTP in order to improve its throughput.  Their suggestions for writing scalable Erlang programs include:  preferring os:timestamp to erlang:now and partitioning ets and mnesia tables in order to localise access to smaller number of processes. They reached 2.5M+ concurrent connections/box from an initial server load of ~200k connections. They found that Erlang has *awesome* SMP scalability,  as it can reach >85% CPU utilization across 24 logical CPU cores uniformly and the CPU utilization grows almost linearly with the number of connections.

They have published as open source all their changes here.  Some of their suggestions are now enabled by default (e.g. number of memory allocators being equal to the number of schedulers in the VM) but most of their changes are not included as they are system-specific.

]]> Companies, Erlang Solutions 2012-05-10T17:01:14+00:00 Erlang Common Test Continuous Integration http://www.planeterlang.org/en/planet/article/Erlang_Common_Test_Continuous_Integration/ http://www.planeterlang.org/en/planet/article/Erlang_Common_Test_Continuous_Integration/ Eric B Merritt A

]]> Blogs, Erlware 2012-05-09T17:01:52+00:00 11 May 2012: Krakow Erlang User Group http://www.planeterlang.org/en/planet/article/11_May_2012_Krakow_Erlang_User_Group/ http://www.planeterlang.org/en/planet/article/11_May_2012_Krakow_Erlang_User_Group/

Further Details

Date : 11 May 2012

Time : 16:00

Location: Szpitalna 38/3a, Krakow

Email Katarzyna.kraus@erlang-solutions.com to register

 

The Programme

Rebar – building and converting a project

The first part of the presentation describes the process of building a new project using Rebar - including the catalogue structure and required commands. The second part demonstrates a conversion of an existing project from a generic build system to Rebar.
This presents one with an opportunity to examine the crucial configuration parameters as well as ways of solving common Rebar problems.
The project I chose to converse is Streamfile - a filehosting service.  Currently it operates on a build system probably designed for a different service. It has a complicated structure and sometimes build errors are difficult to solve. The goal is to build Streamfile using a clear structure of catalogues and configuration files. Thanks to the complexity of this project, the demonstration will cover a whole range of tasks: from libraries to C code compilation.

 

About Piotr Nosek

I’m a Polish employee of Erlang Solutions, who (to be honest) never thought he would have an occasion to work with such a great IT team. My adventure with Erlang began early in my studies, but the real stuff started with Erlang by Example course. I didn’t suspect that ordinary programming course will end up with a job interview. And thus I’ve been here for over 1.5 year, really enjoying projects from all around the world.
My main area of expertise so far covered webdevelopment in Erlang. My priorities are slowly shifting now, but still sometimes I have an occasion to work on our company websites.

As a hobby, I’m interested in applying Erlang in online gaming. For me, this is something completely new, so I’m at the beginning of a whole journey but I really hope to develop my skills in this matter. Also I’m still trying to find some time to further develop my open source project, which is C library for Riak.



]]> Companies, Erlang Solutions 2012-05-09T16:01:24+00:00 You, Too, Can Be on the Cutting Edge of Functional Programming Research http://www.planeterlang.org/en/planet/article/You_Too_Can_Be_on_the_Cutting_Edge_of_Functional_Programming_Research/ http://www.planeterlang.org/en/planet/article/You_Too_Can_Be_on_the_Cutting_Edge_of_Functional_Programming_Research/ James Hague In 1999 I earned $200 writing an essay titled Toward Programmer Interactivity: Writing Games in Modern Programming Languages. It was an early, optimistic exploration of writing commercial games in Haskell, ML, and Lisp.




It was not a good article.




It’s empty in the way that so many other “Hey everyone! Functional programming! Yeah!” essays are. I demonstrated the beauty of Haskell in the small, but I didn’t offer any solutions for how to write state-heavy games in it. There are a few silly errors in the sample code, too.




Occasionally during the following years, I searched for information about writing games in functional languages, and that article kept coming up. Other interesting references turned up too, like papers on Functional Reactive Programming, but apparently I had accidentally become an authority. An authority who knew almost nothing about the subject.




I still didn’t know if a mostly-functional style would scale-up past the usual toy examples. I didn’t know how to build even a simple game without destructive assignment. I wasn’t sure if there were even any legitimate benefits. Was this a better way of implementing game ideas than the usual tangled web of imperative code—or madness?




As an experiment, I decided to port an action game that I wrote in 1997 to mostly-pure Erlang. It wasn’t a toy, but a full-featured game chock full of detail and special cases. I never finished the port, but I had the bulk of the game playable and running smoothly, and except for a list of special cases that I could write on a “Hello! My Name is” label, it was purely functional. I wrote about what I learned in Purely Functional Retrogames.




Now when I search for info about writing games in a functional style, that’s what I find.




Sure, there are some other sources out there. Several times a year a new, exuberant “Haskell / ML / Erlang is a perfect match for games!” blog entry appears. Functional Reactive Programming keeps evolving. A couple of people have slogged through similar territory and managed to bang-out real games in Haskell (Raincat is a good example).




If you want to be on the cutting edge of functional programming research, it’s easy. Pick something that looks like a poor match for state-free code, like a video game, and start working on it. Try to avoid going for the imperative pressure release valves too quickly. At some point you’re going to need them, but make sure you’re not simply falling back on old habits. Keep at it, and it won’t be long before you’re inventing solutions to problems no one else has had to deal with.




If you come up with something interesting, I’d like to hear about it.




(If you liked this, you might enjoy Back to the Basics of Functional Programming.)

]]> Blogs, Programming in the 21st Century 2012-05-08T08:00:00+00:00 The Most Important Decisions are Non-Technical http://www.planeterlang.org/en/planet/article/The_Most_Important_Decisions_are_Non-Technical/ http://www.planeterlang.org/en/planet/article/The_Most_Important_Decisions_are_Non-Technical/ James Hague I occasionally get puzzled questions about a parenthetical remark I made in 2010: that I no longer program for a living. It’s true. I haven’t been a full-time programmer since 2003. The short version of these questions is “Why?” The longer version is “Wait, you’ve got a super technical programming blog and you seem to know all this stuff, but you don’t want to work as a programmer?”




The answer to both of these is that I realized that the most important decisions are non-technical. That’s a bare and bold statement, so let me explain.




In the summer of 1993, I answered a newspaper ad looking for a “6502 hacker” (which I thought was amusing; the Pentium was released that same year) and got a job with a small company near Seattle writing Super Nintendo games. I had done game development prior to that, but it was me working by myself in my parents’ living room.




The first SNES game I worked on was a Tarzan-themed platformer authorized by the estate of Edgar Rice Burroughs (it had no connection to the Disney movie, which was still six years in the future). I had fun working out ways of getting tropical fish to move in schools and creating behaviors for jungle animals like monkeys and birds. It was a great place to work, with the ten or so console programmers all sharing one big space.




The only problem was that the game was clearly going to be awful. It was a jumble of platformer clichés, and it wasn’t fun. All the code tweaking and optimization and monkey behavior improvements weren’t going to change that. To truly fix it required a project-level rethink of why were building it in the first place. As a “6502 hacker” I wasn’t in a position to make those decisions.




While it’s fun to discuss whether an application should be implemented in Ruby or Clojure, to write beautiful and succinct code, to see how far purely functional programming can be taken, these are all secondary to defining the user experience, to designing a comfortable interface, to keeping things simple and understandable, to making sure you’re building something that’s actually usable by the people you’re designing it for. Those are more important decisions.




Whatever happened to that Tarzan game? Even though it had been previewed in Nintendo Power, the publisher wisely chose to pay for the year of development and shelve the finished project.

]]> Blogs, Programming in the 21st Century 2012-05-06T08:00:00+00:00 Sinan Releases and Being Right http://www.planeterlang.org/en/planet/article/Sinan_Releases_and_Being_Right/ http://www.planeterlang.org/en/planet/article/Sinan_Releases_and_Being_Right/ Tristan Sloughter A

]]> Blogs, Erlware 2012-05-04T22:33:07+00:00 ejabberd 2.1.11 bugfix release http://www.planeterlang.org/en/planet/article/ejabberd_2.1.11_bugfix_release/ http://www.planeterlang.org/en/planet/article/ejabberd_2.1.11_bugfix_release/ badlop ejabberd 2.1.11 has been released, and it contains several bug fixes, improvements and new features.

The changes are:

  • HTTP service
    • Fix ejabberd_http:get_line
    • Don’t use binary:match to extract lines from binaries
    • Parse and encode https header names like native http parser does
    • Parse correctly https request split into multiple packets
    • Properly handle HEAD request in mod_http_bind (EJAB-1538)
    • New option default_host for handling requests with ambiguous Host (EJAB-1261)

  • ODBC

    • New ODBC support for mod_announce

read more

]]> Software, ejabberd Community Site 2012-05-04T17:06:57+00:00 Erlang Infrastructure Engineer, Silicon Valley / San Francisco Bay Area http://www.planeterlang.org/en/planet/article/Erlang_Infrastructure_Engineer_Silicon_Valley_San_Francisco_Bay_Area2/ http://www.planeterlang.org/en/planet/article/Erlang_Infrastructure_Engineer_Silicon_Valley_San_Francisco_Bay_Area2/ • Experience with writing production-quality software in Erlang OTP, highly scalable & concurrent systems, a double plus!
•  Ability to perform database development ( e.g., designing schemas, when to use stored procedures, understanding of ORM tools, etc.)
• Proficiency in Linux
• Experience building scalable web applications/services
• Experience in distributed computing and multi-tier application development, with experience in developing frameworks, a plus.
• Good communication skills, be able to discuss/defend/document your ideas
• A strong belief or experience in Agile and iterative development approaches
•  A Computer Science or Maths degree, or be passionate about applying the latest software ideas to their personal and professional life.
 
Desirable:

• Be able to do basic Linux administration tasks
• Have experience with one or more of the following:

  • Ejabberd/XMPP
  •  RabbitMQ

 • Be a startup junkie who wants to see a new idea (and company) succeed.

]]> Companies, Erlang Solutions 2012-05-02T15:31:25+00:00 Cowboy and Batman.js for Erlang Web Development http://www.planeterlang.org/en/planet/article/Cowboy_and_Batman.js_for_Erlang_Web_Development/ http://www.planeterlang.org/en/planet/article/Cowboy_and_Batman.js_for_Erlang_Web_Development/ Tristan Sloughter A

]]> Blogs, Erlware 2012-04-30T16:59:11+00:00 Erlang, Cowboy and Batman.js for Building Web Applications http://www.planeterlang.org/en/planet/article/Erlang_Cowboy_and_Batman.js_for_Building_Web_Applications/ http://www.planeterlang.org/en/planet/article/Erlang_Cowboy_and_Batman.js_for_Building_Web_Applications/ Tristan Sloughter A

]]> Blogs, Erlware 2012-04-27T17:11:28+00:00 A Forgotten Principle of Compiler Design http://www.planeterlang.org/en/planet/article/A_Forgotten_Principle_of_Compiler_Design/ http://www.planeterlang.org/en/planet/article/A_Forgotten_Principle_of_Compiler_Design/ James Hague That a clean system for separately compiled modules appeared in Modula-2, a programming language designed by Niklaus Wirth in 1978, but not in the 2011 C++ standard…hmmm, no further comment needed. But the successor to Modula-2, Oberon, is even more interesting.




With Oberon, Wirth removed features from Modula-2 while making a few careful additions. It was a smaller language overall. Excepting the extreme minimalism of Forth, this is the first language I’m aware of where simplicity of the implementation was a concern. For example, nested modules were rarely used in Modula-2, but they were disproportionately complex to compile, so they were taken out of Oberon.




That simplicity carried over to optimizations performed by the compiler. Here’s Michael Franz:

Optimizing compilers tend to be much larger and much slower than their straightforward counterparts. Their designers usually do not follow Oberon’s maxim of making things “as simple as possible”, but are inclined to completely disregard cost (in terms of compiler size, compilation speed, and maintainability) in favor of code-quality benefits that often turn out to be relatively marginal. Trying to make an optimizing compiler as simple as possible and yet as powerful as necessary requires, before all else, a measurement standard, by which both simplicity and power can be judged.




For a compiler that is written in the language it compiles, two such standards are easily found by considering first the time required for self-compilation, and then the size of the resulting object program. With the help of these benchmarks, one may pit simplicity against power, requiring that every new capability added to the compiler “pays its own way” by creating more benefit than cost on account of at least one of the measures.

The principle is “compiler optimizations should pay for themselves.”




Clearly it’s not perfect (the Oberon compiler doesn’t make heavy use of floating point math, for example, so floating point optimizations may not speed it up or make it smaller), but I like the spirit of it.




(If you liked this, you might enjoy One Small Step Toward Reducing Programming Language Complexity.)

]]> Blogs, Programming in the 21st Century 2012-04-25T08:00:00+00:00 Can You Be Your Own Producer? http://www.planeterlang.org/en/planet/article/Can_You_Be_Your_Own_Producer/ http://www.planeterlang.org/en/planet/article/Can_You_Be_Your_Own_Producer/ James Hague I’ve worked on personal projects where I went badly off track and didn’t realize it until much later. What I needed was someone to nudge me in the right direction, someone to objectively point out the bad decisions I was making.




What I needed was a producer.




When a band is recording an album, the producer isn’t there to write songs or play instruments, but to provide focus and give outside perspective. A good producer should say “Guys, you sound great live, but it’s not coming through in the recording; can we try getting everyone in here at same time and see how that goes?” or “We’ve got three songs with similar wandering breakdowns; if you could replace one, which would it be?”




(Here I should point out that a producer in the music production sense is different than a producer in film or in video games. Same term, different meanings.)




If you’re a lone wolf or part of a small group building something in your basement, there’s tremendous value in being able to step back and get into the producer mindset. Maybe you can’t be both a producer and developer at the same time, but recognizing that you need to switch hats periodically is key.




What are the kinds of question you should be asking when in your producer role?




Are you letting personal technology preferences cloud your vision? Haskell is a great language, but you’re writing a lot of code that you’d get for free with Python. Yes, Android is open to some extent and iOS isn’t, but should you be dismissing the entire iPhone / iPad market for that reason?




Are you avoiding doing the right thing because it’s hard? If everyone you show your project to suggests the same useful feature, disregarding it because it would take a month of rearchitecting usually isn’t a valid response.




Are you simply copying existing ideas without offering anything new? It’s so easy to see a finished application and jump into writing your own version. But think about the problem that it was designed to solve instead of copying the same solution. A painting program doesn’t have to use the blueprint laid out by MacPaint in 1984. An IDE doesn’t have to follow the project tree view on the left schematic.




Are you spending too much time building your own solutions instead of using what’s already out there? Should you really be writing another webserver or markdown formatter or JSON decoder?




Do you understand your audience? If you’re building an application for graphic artists, are you familiar with how graphic artists work? Are you throwing out features that would be met with horrified stares?

]]> Blogs, Programming in the 21st Century 2012-04-22T08:00:00+00:00 Use and Abuse of Garbage Collected Languages http://www.planeterlang.org/en/planet/article/Use_and_Abuse_of_Garbage_Collected_Languages/ http://www.planeterlang.org/en/planet/article/Use_and_Abuse_of_Garbage_Collected_Languages/ James Hague The garbage collection vs. manual memory management debates ended years ago. As with the high-level vs. assembly language debates which came before them, it’s hard to argue in favor of tedious bookkeeping when there’s an automatic solution. Now we use Python, Ruby, Java, Javascript, Erlang, and C#, and enjoy the productivity benefits of not having to formally request and release blocks of bytes.




But there’s a slight, gentle nagging—not even a true worry—about this automatic memory handling layer: what if when my toy project grows to tens or hundreds of megabytes of data, it’s no longer invisible? What if, despite the real-time-ness and concurrent-ness of the garbage collector, there’s a 100 millisecond pause in the middle of my real-time application? What if there’s a hitch in my sixty frames per second video game? What if that hitch lasts two full seconds? The real question here is “If this happens, then what can I possibly do about it?”




These concerns aren’t theoretical. There are periodic reports from people for whom the garbage collector has switched from being a friendly convenience to the enemy. Maybe it’s because of a super-sized heap? Or maybe accidentally triggering worst-case behavior in the GC? Or maybe it’s simply using an environment where GC pauses didn’t matter until recently?




Writing a concurrent garbage collector to handle gigabytes is a difficult engineering feat, but any student project GC will tear through a 100K heap fast enough to be worthy of a “soft real-time” label. While it should be obvious that keeping data sizes down is the first step in reducing garbage collection issues, it’s something I haven’t seen much focus on. In image processing code written in Erlang, I’ve used the atom transparent to represent pixels where the alpha value is zero (instead of a full tuple: {0,0,0,0}). Even better is to work with runs of transparent pixels (such as {transparent, Length}). Data-size optimization in dynamic languages is the new cycle counting.




There’s a more often recommended approach to solving garbage collection pauses, and while I don’t want to flat-out say it’s wrong, it should at least be viewed with suspicion. The theory is that more memory allocations means the garbage collector runs more frequently, therefore the goal is to reduce the number of allocations. So far, so good. The key technique is to preallocate pools of objects and reuse them instead of continually requesting memory from and returning it to the system.




Think about that for a minute. Manual memory management is too error prone, garbage collection abstracts that away, and now the solution to problems with garbage collection is to manually manage memory? This is like writing your own file buffering layer that sits on top of buffered file I/O routines. The whole point of GC is that you can say “Hey, I’d like a new [list/array/object],” and it’s quick, and it goes away when no longer referenced. Memory is a lightweight entity. Need to build up an intermediate list and then discard it? Easy! No worries!




If this isn’t the case, if memory allocations in a garbage collected language are still something to be calorie-counted, then maybe the memory management debates aren’t over.




(If you liked this, you might enjoy Why Garbage Collection Paranoia is Still (sometimes) Justified.)

]]> Blogs, Programming in the 21st Century 2012-04-21T08:00:00+00:00 100,000 Lines of Assembly Language http://www.planeterlang.org/en/planet/article/100000_Lines_of_Assembly_Language/ http://www.planeterlang.org/en/planet/article/100000_Lines_of_Assembly_Language/ James Hague I occasionally get asked about writing Super Nintendo games. How did anyone manage to work on projects consisting of hundreds of thousands of lines of 16-bit assembly language?




The answer is that it’s not nearly as Herculean as it sounds.




The SNES hardware manual is a couple of hundred pages. I don’t remember the exact number, so I’ll shoot high: 400 pages. Add in a verbose 65816 assembly language book and combined we’re talking 800 or 900 pages tops. That’s eight percent of the total I came up with for having a complete understanding of an OS X based computer: nearly 11,000 pages.




Sure, there are whole classes of errors that you can make in assembly language that are invisible in C. For example, here’s some old-school x86 code: 

mov ax, 20
mov bx, -1
int XX

This sets up a couple of parameters and calls an interrupt. It looks right, it works, it may even ship in a commercial product, but then there’s a new MS-DOS version and it crashes. Why? Because the second parameter should be passed in the dx register, not bx. It only worked because a previous interrupt happened to return -1 in dx, so the second line above isn’t actually doing anything useful. But those kinds of errors are rare.




The secrets of working entirely in assembly language are being organized, thinking before implementing, and keeping things clean and understandable. That sounds a lot like how to write good Javascript or C++. Steve McConnell’s Code Complete is actually a guidebook for the Super Nintendo game programmer.




But all this talk of programming languages and hardware is backward. Jordan Mechner designed and built the original Prince of Persia on an Apple II. The game and the editor for laying out the levels are written in assembly code for the 8-bit 6502. He kept a journal while writing the game.




You might expect the journal to be filled with coding philosophies and 6502 tricks, but there’s little of that. Sure, he’s doing difficult tech work behind the scenes, but that’s not what he’s writing about. They’re the journals of a designer and a director, of someone living far away from home after graduating from college, with long detours into his screenwriting aspirations (and don’t let that scare you off; they’re fascinating).




He may have had second set of coding journals, but I like to think he didn’t. Even if he did, he was clearly thinking about more than the techie side of things, in the way that a novelist’s personal journal is unlikely to be filled with ramblings about grammar and sentence structure.




(If you liked this, you might enjoy The Pure Tech Side is the Dark Side.)

]]> Blogs, Programming in the 21st Century 2012-04-13T08:00:00+00:00