Arc

March 3rd, 2008 § 0 comments § permalink

Arc’s Out:

Arc is still a work in progress. We’ve done little more than take a snapshot of the code and put it online.

I’ve working on this for a long, long time and realized I’ll never get it done properly so I’ll release it anyway.

Why release it now? Because, as I suddenly realized a couple months ago, it’s good enough.

It’s shit but I’m famous enough that people will be talking about it for a long time. People will think it’s good even if it’s really just a bunch of macros on top of Scheme.

I worry about releasing it, because I don’t want there to be forces pushing the language to stop changing.

I’m not going to change it, but if you idiot enought to want to use it, remember that there’s not documention. In other words, don’t call me if you can understand a single line of the code.

Which is why, incidentally, Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. (…) But the kind of people who would be offended by that wouldn’t like Arc anyway.

I don’t understand and don’t care for any other character set other than my precious ASCII. I learned it forty years ago and I’m not giving it up now. No way. Ah, that why Yahoo! completely rewrote the application I sold them. Bunch of losers.

Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.

Also, I don’t understand anything about new and modern standards and technologies like XHTML and CSS. And I’m not waste my precious VC time learning them. And I don’t care about you people who dare to make the Web less complicated. Did I mention why Yahoo! had to rewrite the program they bought from me?

Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means.

I told you. I don’t understand anything about HTML.

So experience suggests we should embrace dirtiness. Or at least some forms of it; in other ways, the best quick-and-dirty programs are usually quite clean.

Look! A dumpster! Let’s have some fun!

Arc tries to be a language that’s dirty in the right ways. It tries not to forbid things, for example. (…) For now, best to say it’s a quick and dirty language for writing quick and dirty programs.

I lost so much time with this shit that the world should share my pain. Basic, watch yourself. It’s Arc time! Agora é a vez do Arc.

The Pragmatic Programmer

March 2nd, 2008 § 2 comments § permalink

This is another book about software as a craft but written in a style that’s much more interesting and accessible. Dave Thomas and Andy Hunt have a lot of experience in the field and it shows.

Most of the advice given is pretty obvious but every programmer should remind himself now and them of what’s important to his programming career. This book does exactly that.

Most of the advice provided in the book is in those areas where programmers have more trouble–like communication and dealing with managers. That’s very necessary, considering how much more integrated progamming has become today, and more so in Agile contexts where outside interaction is paramount. But there is also a lot of practical advice about the best way to prototype, how to handle the problem domain in terms of languages choice and lots of similar subjects.

Also, reading this book reminds me again of how bad Software Craftsmanship was. McBreen really sounds like he read this book, had a couple of nice insights and decided to write an entire book on what should have been an article or an essay.

Of course, two of the most interesting parts of the books are the challenges and exercises. The challenges are questions about the text just read, leading the reader to expand his comprehension and think about the way what has been just learned applies to his work. The exercises, on the other hand, are more about practicing the knowledge in code. Both are good tools to make sure the knowledge acquired in fixed into the reader’s memory.

Of course, the book is not without flaws although many of them may be attributed to the time in which it was written. For example, there is a tendency in the text to present Java and its related technologies as leading the way to the future. But those are small problems in a otherwise great book.

The ending was a little slow, as well, in face of everything that was already said but I would encourage readers to stick with the book. Even in the slow chapters there a lot of food for thought.

All in all, this is a practical and current book that will benefit every programmer reading it. Even programmers with a lot of experience will learn something or at least be reminded of things they should be doing and may not be doing right now. I strongly recommend it.

Where am I?

You are currently viewing the archives for March, 2008 at Reflective Surface.