deafbybeheading

The tour has the unfortunate property of being both a top result for many golang searches and not being deep-linkable. I welcome additional introductory material.

Go is an excellent contrast. Not only is the syntax spartan, but--especially if you include the built-in formatter gofmt--it has a fascist insistence on a uniform coding style. I don't agree with all its stylistic decisions, but I'd rather live with them and have consistency than run into corner cases and gotchas.

And (as you note above), is 2.5 still getting critical bug fixes? There's a thin line between stable and stagnant.

I don't know what to make of this change. I always assumed goto was something you designed into your language from day one, rather than bolted on in day 4000 or so. Can someone more familiar with language design (or the target use cases--I presume high-performance game programming?) comment on this further?

It's not. And you're right, the spec isn't clear. On the other hand, the current behavior of pretending the bits are arranged in 32-bit two's-complement fashion for appropriate integer values when applying bitwise operators is really the only sensible interpretation (especially since a 64-bit float can represent all 32-bit ints).

So can someone recommend a Ruby (edit: ideally Sinatra/Sequel, not Rails) app one could look at with a more principled test suite? I'm coming from a more traditional OO background and jumping into Ruby. It's good to see I'm not alone in finding this militant pragmatism somewhat off-putting, but I don't want to reinvent the wheel.

I'll second that. The first release with Unity (11.04?) was dradful. The second fixed some major issues, and now it's perfectly usable (unless you're particularly set in your ways). I run 12.04 on an older Eee, and it's not noticeably faster or slower than when I was running Xubuntu before.

Is it? One could argue that divorcing widgets from backend infrastructure so thoroughly is an asset.

To me, a turning point in my feelings on UX was reading Alan Cooper's "The Inmates are Running the Asylum" [1]. It's a little anti-engineer (he argues that engineers cannot do this right and you always need dedicated UX people), but he explains core interaction design principles very well.

E.g., he draws a distinction between mere UI design and interaction design: UI design is just layering another abstraction (the interface in question) on the underlying software architecture, whereas interaction design starts with what the user wants to accomplish, and adapts the underlying pieces to enable that.

Note that this is not a UI book, or even really all that much of a UX book, but it does make a great argument for the importance of user interaction.

[1]: http://dl.acm.org/citation.cfm?id=553473

The problem was that the HTML-plus-JavaScript paradigm was never meant for building applications. Sure, you don't need a framework if you're just sprucing up some web pages, but if you want to build a desktop-like app in the browser [1], it's nice to get a leg up from something that understands that sometimes we need the humble web page to be something more.

Don't get me wrong--there's plenty of ways for frameworks to get this wrong, but the overall idea is not inherently useless.

[1]: And why would you want to do that? Because desktop apps never evolved some killer features of the web app: lightweight, cross-platform, zero-install, a passable remoting API, and sandboxing.

This reminds me of Alan Cooper's "The Inmates are Running the Asylum," where he argues that you can't please everyone and you should not be designing an application to solve all possible use cases because that's doomed to failure (or, at best, mediocrity). You can do better making a killer solution for 80% of your potential users than you can trying to address the needs of all potential users.

I used to think this, but my W520 has had more than its fair share of graphics problems (especially when I naïvely started with the Canonical-recommended 32-bit install; I've since gone 64-bit). It still won't link to an external display (at least not without rebooting, which I haven't tried but is a complete non-starter for me). Other than that, it's pretty solid.

Someone pointed out zareason [1] in another thread; I may give that a shot next time.

[1]: http://zareason.com/shop/Verix-2.5.html

>Depending on your application and how you're taking advantage of your database, you could drop-in replace a database.

If you're doing something simple, sure, maybe. But beyond trivial things like DDL syntax and query syntax, there's query optimization (even when only going in via ORM, because schema design can affect this), tuning, backups, HA, monitoring, and a dozen other things.

You're already making a huge non-portable investment in using a complex tool like a database. In comparison to this, introducing dependence on its non-standard features is pretty small change, so you might as well stop worrying (considering how seldom people actually migrate), raise a glass to YAGNI, and learn to love your database.

Maybe in another five years your or some successor will end up cursing the day you made that decision, but if you could really use non-standard feature X and it's sitting right there in front of you, it's silly to shun it "just in case."

Well, to be fair, MySQL has a storied history of implementing 95% of a feature, calling it good enough, and shipping it.

And while, as a Postgres user, my tone here may be a little snide, I also say this with grudging respect: I think there is a point at which implementing n% of a feature X and calling it X (rather than MaybeX or MostlyX) does give you some momentum and practical compatibility that you wouldn't have otherwise. Is it dishonest to hide the limitations regarding the edge cases in some documentation no one will read? Maybe. But will providing the feature solve more problems than it causes? Quite possibly.

I don't agree with MySQL's decision with respect to UTF-8, but I do understand it.

I think what alttab was saying is that you should still post updates without assuming you're just talking to a bunch of clojure aficionados.

E.g., I'm somewhat interested in LT but for the other languages. I'm curious enough to check out the odd blog post now and then, but if it's all gibberish, I won't come back and may lose track of the project and miss the other language support when it does land.

Python does (5) and it's pretty refreshing. I'm sure other languages with more elaborate type systems do as well, but it's nice to see in an ostensibly "scripty" language.

I think another interesting thing to note is that many languages that do make a distinction (at the type level) between integer types and floating point types (that is, ones like IEEE 754 floats with defined NaN and +/- Infinity behavior) do allow 1f / 0f [1], but raise an error on 1 / 0. Avoiding automatic type coercions (either between ints and floats or between floats and strings) would make it more clear what actually happens in that case.

[1]: Except, apparently, Python! Who knew: http://bytes.com/topic/python/answers/769104-turn-off-zerodi... ?

Indeed. User-defined aggregates[1] are another great tool, and complement user-defined types very nicely.

[1]: http://www.postgresql.org/docs/9.1/static/xaggr.html

ActionScript running directly in the browser could be interesting. It has some cruft (much of it shared with JS due to the ECMAScript heritage), and the ECMAScript lineage leads to some weird features (e.g., typically its class-based inheritance is used, but it does include prototype inheritance), but it's not a bad language.

How does

    (ternary (false) (integer 15) (integer 15))

help JIT?

>I think we are starting to get to that point with relational and nosql. Tools are starting to emerge on the relational DB side to allow more nosql-like structures within traditional DBMS systems. I think in the coming year or two we'll start seeing a lot more interesting tools to mix relational and non-relational datastores.

Yep. Postgres showed some pretty strong commitment to key-value datatypes in 2006 by including the hstore contrib module in the mainline tree, and native JSON support is coming in September with 9.2.