triplefox

A thought I had today is that programming is a perpetual battle between "if it ain't broke don't fix it" and "computers are here to make our lives easier." Doing one impedes the other.

To answer in sort of a roundabout way, I think the problem domain matters a lot for how much you relatively learn when switching languages.

With web app backends, for example, most of the problems somehow relate to difficulty maintaining state over widespread, always-on networked systems - things like authentication, sessions, concurrency, large-scale, flexible datastores. So the systems architected gradually get more and more tuned towards serving this particular goal with little programmer effort. And because those problems are a good match to functional programming - because it eliminates state - functional has become popular.

But if you were building an embedded system, statefulness is less of a problem: there's usually only one thread, and all memory can be mapped in an orderly way. Your performance constraints are reliant on a single fixed platform, so the methods of inspecting and debugging code change.

So to get back to the original question, think about reframing your familiar problems in a way that would simplify the solution with a functional technique. Preferably, look for simplifications that are really big changes and throw out traditional assumptions - the use of relational databases in webapps is one common target for this. Even if you get it wrong you'll get a better understanding of where the functional solution can and can't work.

The problem back in the day was always documentation and concept-acquisition. To some extent documentation is still a problem, but at least with modern languages a lot of the APIs and data structures for common tasks are sitting at your finger-tips, you don't have to reinvent them, so "throwing something onto the screen" is a faster process, and you usually get much more helpful error messages.

The concepts are still problematic though.

I find it somewhat amazing that the orders of magnitude difference isn't larger.

Make a high-speed train startup?

Many modern games have taken the trend of just dumbing down the gameplay so that what the player actually has is not at all about challenge, but just an experience, with some gameplay mechanics as added-value.

The puzzle-genre version of this might be otherwise known to you as "casual gaming." Bejeweled, Peggle, etc. take almost no conscious effort to play, even though skill elements exist.

Parkour has a purity to it that is hard to find in most pursuits. The thrust towards utility and awareness of one's own environment distinguishes it from "stunt performance." Danger and physical challenge are only part of the picture. It really invites a more reflective mode of thought than other athletics.

I've followed the "Programmer's Stone" concepts off-and-on, almost forgot about them entirely. This is definitely the best iteration of them yet.

This is highly unsurprising. You can extrapolate it to online venues like this one - most of the articles are actually a reply in some ongoing global dialogue, and over time those topics tend to calcify into a set of repetitive memes.

I don't really think we can escape this unless we constantly reform into new groups.

It is entirely a technical limitation of Flash. You have no way of guaranteeing a set sound latency, or even monitoring how much is present. According to the Adobe devs this might change in future versions.

But for right now, music games on Flash can't live up to the expectations set by games on other platforms.

I am an avid haXe user. It has static inferred typing with a "Dynamic" type, "untyped" blocks, and casting, all of which work more-or-less as advertised: the type system gets out of the way when you ask it to, and the rest of the time you get nearly-free type-checks. Sometimes it needs a little bit of annotation to help it along, but on the whole it's very handy for refactoring code.

In fact, I'm sure my iteration time goes up in haXe because I see most errors at compile-time. The ones I don't see are logic and uninitialized values.

ed: I mean time goes down, not up. Progress goes up.

Within a large city, the difference between one public school and the next can be the difference between a serious study environment, and an environment where the majority are in gangs or come from broken families, and class is disrupted on a daily basis.

The explanation is simple: the factors that separate the ghetto from the toniest parts of town will feed into a school system based on geographical location.

School busing has been tried as a solution to this, but it causes other problems - expense, high commute times, and a environment where some of the kids are at an obvious - and painful - advantage to others. The parents in a good neighborhood will fight against busing, if it could put their kid in a worse school. The parents in a bad neighborhood may have too many other problems to be concerned with their kid's education.

Signs are accumulating that the industry is going to shift towards lower-budget projects because the blockbuster-centric model has become unsustainable on multiple levels - cost+time risks, a uncertain future consumer market, technology hitting a plateau of diminishing returns, and, of course, growth in online+downloadable. With lower budgets, the projects are less sexy, but also have less room for catastrophes, crunch included.

I believe that this kind of future environment is more likely to encourage sustainable practices. Studios working consoles and retail are traditionally forced towards heavy turnover because the market economics dictate it. But in a low budget and predominantly online market, a small studio suddenly has a lot of room to make an impact on their own, without leverage.

Most studios really do want to hang on to their people, and this coming decade may be when that becomes the norm.

There is a parallel to this in music called Gear Acquisition Syndrome; when you crave new gear in hopes of stoking inspiration or improving your sound, even when this is a dubious proposition at best.

People with too much GAS tend to be much like language weenies. They will go to absurd lengths to defend the "pure/fat/warm/etc. sound" of their favorites, an ultimately pointless endeavor considering that after a certain minimum of instrument quality, playstyle and post processing effects will both have far more impact.

Interesting that you mention that given that dental health is already directly linked to cardiovascular health, via incidence of inflammation and gum disease.

To take this to an extreme, you could simply ask people - off or online - "Do you ever have problem x?" implicitly asking about the problem your product will solve. The more responses you get, the more you'll know you're on to something.

I downloaded it and what I saw was the very empty beginnings of a game engine.

Edit: Also, the documentation persistently says "it's very simple to ---" and then dumps a code example on you without actually explaining the concept.

It's already too late. It's gotten worse every day for the last month, I think.

There is a certain universality in the "Forth philosophy" across many developer communities. (one could stretch it to include life too, but it gets a bit tired at that point)

Unix wizards believe in "Worse is Better."

Lisp and Smalltalk hackers like to have a system that is "elephants all the way down."

The Zen of Python says "There should be one-- and preferably only one --obvious way to do it."

Rails popularized "Convention over configuration."

The specific interpretations vary, but implicitly, they all deride the obvious alternative: piling on layers of heavyweight complexity to gain some perceived flexibility and modularity.

Meatball Wiki is a good general source of wiki advice: http://www.usemod.com/cgi-bin/mb.pl

I recall reading on it somewhere the point that there are several possible formats of wiki - namely, the "discussion" format and the "document" format, and that Wikipedia has has made familiar the concept of cleanly dividing the two into separate pages. You might want to reconsider this concept and how it works in the context of a review.

The other main thing to consider is whether you can apply the same template and rules over every page - if you can, it's very straightforward to contribute.

We are cyborgs. Our technology is not orthogonal to our biology.

I think many developer tools - and perhaps Unix-style tools in particular - suffer from this problem of skipping past concepts to syntax. There's an inherent expectation that you aren't a user who wants just the "shallow" common-case uses, but instead are going to go through a rite of passage where you learn the ins and outs of all the concepts the tool uses, make it part of your daily life, and piece it together with the other small powerful tools into some conglomeration that solves your problem.

This is great for developers, but bad for end-users, as a lot of users will run away before learning new concepts(they're busy enough already), while others will take a macho posturing attitude towards it and look down on the people who ran away. The community gets polarized. Git exemplifies this kind of thing, for better or for worse.

It's not a huge surprise that so many developers have switched from Linux to OSX, since the latter has made many more provisions towards the newbie end-user; it indicates that most developers don't want to take on this kind of burden, at least not all the time.

Latency is only "solved" in modern games by hacking around things on both the client and server so that visual indicators are predicted on the client, and conflicting interactions(e.g. two players firing and killing each other simultaneously) are resolved by rolling back game state and examining the timestamps. It's unclean.

It was indeed down in the early morning.

I don't think it's NIH exactly, but a certain laziness and unwillingness to try anything but the simplest(even stupidest) solution. My observations and personal experience indicate that a 10x will reuse formats, languages, and protocols, and they'll use libraries for the purpose of taking advantage of those things.

What you won't see reused is more high-level functionality. That's where a lot of assumptions have to be made about the program's internal structure, and it's where getting too generic and open-ended makes things very complex very quickly.

I think it's supposed to be avant-garde.

A one man company can easily create jobs if it hits the right niche and unlocks a sub-market of related goods and services. So no, you definitely don't have to get big.

Lua is well-liked because it's runs very close to C and easy to embed against, it's Algol-like, it has no dependencies beyond C itself, and it performs decently. It isn't as widely used as Python or Ruby because being embedded means it has a tiny standard library, and correcting that would go against the strengths of the language. (There's code and libraries out there, but it's all fragmented)

That said, the community is out there, and pretty widespread.

I've never seen this before, but it's definitely a case of being about organization, not tech. It's the difference between "wiki technology" (trivial) and "Wikipedia" (non-trivial).

The owner retains the right to refuse service.