coldnebo

Two things:

1) The grammar and writing style has some problems with run on sentence fragments. Perhaps this is not the OP's main focus, but learning to code well is similar to learning to write well (in fact there was an article about this posted to HN a few days ago).

2) By focusing on the idea of 'the best' code, the OP implies some kind of fitness function, but is pretty vague about what that might be. The most obvious fitness function in this context would be that the code works and was written faster than anyone else. Why talk about best-practice and industry standards if your fitness function is speed of writing and correctness?

Experienced programmers don't talk about the "best" code in general, but rather the best code for a given purpose. Code clarity, speed of execution, elegance, reuse, size in memory... these are all different fitness objectives that have various trade-offs... even saying "yeah, I want ALL of those!" implies trade-offs.

It's like saying you want a D&D character with all max attributes... it doesn't work that way.

But there's also a problem with this model of learning. The fastest coders are going to likely be the coders who already know what they are doing, or who work out cheesy ways to game the system. Likely, their incentive for playing will be showing off, not genuinely helping others learn.

Meanwhile, coders who are learning will always be slower. Yes, they will see a lot of other possible solutions, but without critically understanding the differences between code examples, it all becomes a sea of noise. Stack Overflow is already like this in places -- many answers don't demonstrate an expert analysis of a problem, they simply devolve into: "I tried this", "I reinstalled", "Yeah, it works!", "I'm still having issues".

Now, if bitlean's 'tail' in the game was a nice social community built around commenting and critiquing code AFTER it was written and judging its fitness for various stated purposes -- then I could see that really building a community of value for learning programming similar to the ways that we learn critical reasoning in writing courses by contributing to critique and discussion.

'Fast' has its purposes. For example, in Shamus Culhane's book "Animation: from Script to Screen", he talks about the advantages of sketching fast without critical interruption to maintain creative flow. He was adamant about not even erasing one wrong pencil line because it brought critical analysis into the process and disrupted the flow. However, after the sketches capture an idea, that work was always followed by extensive analysis and critique to see where ideas and execution could be improved.

In my experience, I've seen some incredibly smart people (the kind who ace those brain teasers) make some incredibly bad technical gaffs.

Like an architect who chose synchronous HTTP as a protocol for a service that later required the ability to cancel long running operations in progress (he unfortunately didn't realize why hitting the browser stop button wasn't the same as cancelling the process on the server).

Or a senior dev who thought that a JSP scriptlet getting the current time would show the client's time, instead of the server's time.

There is no guarantee that people who ace brain teasers will necessarily be able to figure out technical issues, although they are often excellent at sounding like they have figured out technical issues when they leave the details for the people who get the real work done.

> Of course, I do not install personal software...

> My remedy is to install a virtualization system...

which is personal software.

IMHO, the biggest benefit from playing games like SimCity is the practical introduction to systems thinking: the obvious solution may not be the obvious solution. I often wonder if these games are giving this generation an intuitive grasp of systems dynamics that older generations simply don't get.

The meta-game of effective systems design is fascinating in its own right, because the skills learned apply to real-world systems as well.

I wonder if anyone has tried modeling the problem specific to the game using something like trueworld? http://www.true-world.com/htm/en/index.html

It doesn't cover machine learning in a lot of detail (there is one dogs and cats example) but J. Nathan Kutz book is an excellent introduction to the math behind this and other data modeling techniques with lots of hands on examples. The best thing about this book is that it is a broad survey of the maths you need in Data Science -- you get a feel for how various subjects fit together from a high level with practical examples, then you can branch out to other sources to learn more about specific methods.

* http://www.amazon.com/Data-Driven-Modeling-Scientific-Comput...

I had to laugh when I saw my response next to @getsat's. Both are valid viewpoints. In other words, not everyone who uses tools has to know how to make tools.

Tool makers have more insight into the assumptions behind the tools they create -- they might know how a tool was meant to be used and what its limits are. That being said, there are times when using a screwdriver as a hammer is expedient and does no harm. Of course, there are other times where using Black-Scholes to model a high-volatility market outside of the 'smoothly differentiable' market assumptions it was built on can crash a large part of the economy. It can be a dangerous game to use someone else's tools without knowing their assumptions.

As for applied math suggestions:

1) Watch Feynman's take on applied math in physics: https://www.youtube.com/watch?v=obCjODeoLVw

2) Read this essay "A Mathematician's Lament" which points out the math learned in school is likely not really mathematics and that surprisingly math is not practical but aesthetic -- mathematics is closer to art than we are taught: http://www.maa.org/external_archive/devlin/LockhartsLament.p...

Programming skills are math skills. For example, how would you prove that your code is the fastest possible for a given task? A hunch? A stopwatch? Would it make a difference if you used a different language or machine? What if you could objectively compare the algorithm performance itself without conflating factors? What if you could prove it to others without having to simply trust that you are right? This is math. This is why you can't solve the halting problem or lossless compress past the Shannon limit no matter how hard you try. But it's also why a simple fractal contains an infinite universe of complexity. Don't be afraid of math, embrace it! Find some good teachers/books and maybe you'll find that math isn't some arcane priesthood setup by mathematicans, but that it's the language of nature, the most practical and precise way we have of explaining and understanding these things.

> you can represent anything

If you represent something, you need to interpret it later... i.e. both client and server need the same interpretation in order to avoid errors.

> Dates can be encoded as strings and so can most of the other more 'awkward' types.

You say 'encoding', I say 'serialization'.

> It's not that complicated

It isn't as long as you use the same platform for encoding and decoding.

Maybe our experiences are different. I remember one time I had to unencrypt a string in Ruby that had been encrypted in Java. I thought, this will be simple, it's a standard AES encryption, I'll just stuff the string into the corresponding Ruby object and decrypt! I mean, both of these objects were implemented according to the same industry standard right? Boy was that a learning experience. :) Framing, padding and seeding was not implemented the same way -- it was left as a platform implementation detail that only someone trying to integrate across systems would ever notice.

The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler.

Here's a very simple example of marshaling comparing Marshal dump and load in Ruby using YAML, vs. custom JSON marshalers: http://www.skorks.com/2010/04/serializing-and-deserializing-...

Note that the post shows a tree structure in YAML because Marshall gives it to you for free (synonymous with Java serialize behavior). But the post punts on implementing the same tree in JSON, probably because it's messy and complicated.

Nothing about that looks simple to me. For example, the JSON class label "A" has to be interpreted by something to actually instantiate an A Object. YAML is a bit better-- it at least defines that there is a Ruby class instance being marshaled -- but it doesn't help you if that class doesn't exist the same on client and server.

Pretty soon this leads to madness in production systems where the server evolves "A" (v2) among a sea of separately evolving clients "A" (v1, v1.1, v1.2). Then versioned class annotations get introduced, followed by attempts to differentiate between serializable and non-serializable fields, deep and shallow serialization, etc. etc. Pretty soon, your JSON marshaling isn't so simple anymore.

I should have been more specific... it's not really about trees per se, it's more about custom types. (I was thinking of trees of custom types).

There is a lot of confusion between typing systems, metatyping systems (that can implement arbitrary type systems) and the transport representation of such systems.

I agree with your counterpoints, but the cool kids are still having issues with transport representation of arbitrary types. Sure (eg Ruby) can use Kernel dump and load to marshall arbitrary types, but what happens when the other end doesn't have the type loaded or available?

Ouch, maybe we should invite Java Enterprise Beans to the party to comment on the semantics of distributed types?

JSON is currently deceptively simple precisely because its wire representation (with simple types) is equivalent to its type definition which can be directly evaled in js to produce a memory instantiation. But none of that holds in the general case... Try for example marshalling a JSON object with a tree structure.

Maybe we end up going in Alan Kay's direction, where we stop trying to send representations across the wire and just send code... But that too was tried in the past. It has other limitations.

It's complicated.

Flashback to the early days of XML: "oh god, why would anyone use something as bloated and slow as CORBA to define an interface! Look how simple XML is, and it's human readable!!"

CORBA is laughing its head off: "Who's bloated and overly complex now, eh?"

XML: "Well at least I developed an appreciation of the problem domain... Unlike those arrogant JSON kids"

CORBA: "You were the same way at their age."

XML: "Sure was, gramps!"

(Both chuckle)

I read the essence of that statement without the same time constraint applied to it. i.e. the type of 1000 lines you should be working on each week is the type (systems code) that enables (application) programmers to write the rest of their code effortlessly.

e.g. Rails core (system) vs people who use Rails (applications).

Pay-to-win is also usually an artifact of gameplay that isn't fun, but requires long stretches of time (ie 'the grind') to complete. Considering the video and the fact that your minions carry on their instructions even when you are logged out, I'm not sure there is a traditional grind component in play here?

Also, people are assuming a black market of scripts will develop just as it does for gear, etc. gear is different because the frequency table is fixed -- therefore the competitive landscape is fixed. When everyone can have 'nukes' the winning strategy is no longer 'nukes', it's who can sneak through defenses and disable the nukes, or confuse them.

Kauffman calls this constant evolution into the 'adjacent possible' -- and if Screeps even half delivers that kind of depth, there won't be a stable end state to the game where everyone has one master script. Changing environments necessitate changing response. You are part of the environment. Feedback and permutation!! Yes!!!

Nonsense. :)

Unity has really driven home the popularity of Mono as a cross-platform code platform -- there are tons of people using it who wouldn't necessarily consider themselves .NET programmers. (yes, I realize there's a mix of library, language, and APIs in that soup).

But Mono merging with real .NET crossplatform support suddenly makes it a viable api for all sorts of non-microsoft use.

Back in the day, I remember how badly I wanted the dataset controls from .NET -- they have all this nice built-in functionality manage partial datasets from MSSQL to client memory and then sync multi-edits back to the database again (round trip). It's possibly the best round-trip data controls I've ever found in a library and it's mostly unheard of outside .NET circles. It makes the libraries that jQuery and Rails use

We have a lot to learn from each other -- I'm glad that MS has taken this step forward to embrace cross-platform again in such an open way.

Er, the visual design is cool, but there are a lot of little things wrong with the info graphics. E.g. Showing Neanderthal to recorded history time range with a satellite above the middle of such time range is artistically valid, but misleading in information design and visualization.

Sometimes, the infographics are completely wrong. The "weird no time zone" before the Big Bang is complete bullocks -- the whole page has built the expectation of meaning in the relation of how much time has passed between marks -- implying that the universe has existed for longer "with time" than "without time", which is scientifically meaningless.

I'd like to like this site, but it makes strong data statements without citing any sources and the visual design potentially misleads as much as it informs.

I think we're saying that most modern polyfills do a feature check before installing the polyfill... thus if you use Chrome with an IE agent, the polyfill still checks before implementing -- it's just a little slower than not installing the polyfill to begin with. Anyway, given the percentage of people who do this, UA detection seems like an acceptable tradeoff.

This is cool, but I'm not sure what's going on here. Is this full static (i.e. AST) analysis of these languages or simple full-text search, or some middle-ground constraint on full-text search driven by common usage patterns?

For example, "d3.timer" doesn't show meaningful results?

From a computer science perspective it is formally 'meaningless' because the performance improvement was made by changing the requirements, not by a novel algorithm or data structure. This is always possible, but it ignores the original constraints of the problem and hence doesn't shed any additional meaning on how to solve the original problem.

From a programmer perspective, that might not change the fact that it's useful. It has 'meaning' to the programmer in that it helps us solve a particular problem. Typically, app programmers are not as concerned with how the problem was solved.

I like the library, but to avoid this kind of criticism, don't call it a reimplementation. Call it what it is, an alternative library of functions.

Over the past few years, I've put myself out there as well, not because I'm extroverted but because there is no better laboratory test of your ideas/convictions.

I'd only add one thing to this approach: make sure that you are at least solving one of your own problems and that the solution is real -- i.e. it really benefits you in some measurable way.

I did this a few years ago with a relatively obscure gem that solved a real problem I actually had with refactoring business logic. I put it out there to get feedback on it and was rather disappointed with the initial reactions ("You don't understand MVC!" "You've done it all wrong!"). But I put myself aside and tried to understand the feedback from their point of view.

One thing that became obvious is that most people didn't see the solution as valid because they had completely different context and approach. Fair enough. There were also several that simply 'cargo-culted' mvc responses without realizing that my gem was a thin wrapper around methods that DHH had already put in Rails (so if I didn't understand MVC, neither did he! ;) And no one commented on the biggest problems I legitimately saw with my approach: thread-safety and closures on controller instances in a prod env.

But none of that stopped this gem from being incredibly useful as I tried to break apart a giant monolithic legacy app that challenged traditional refactoring approaches. Maybe it's not perfect, but at least it's a way forward.

So the moral of the story is: put your idea out there, expect feedback and criticism (maybe only criticism since the people who like things tend to keep quiet (e.g. the rvm story last year)) -- but so long as this thing is useful to one person (only you?), use it to make your life easier!

If it's useful to others, that's a bonus learning opportunity, but that shouldn't be your sole motivation.

Heh, I had the same thought and was able to hack it pretty fast: http://runnable.com/U4x1Dioc6NMZvMy0/linear-scales-in-c-like...

Enjoy!

Dear website users,

We feel your pain. It may not seem like it since we develop ever more complicated UI schemes to overcome the W3C's frankenstandards (seriously, who comes up with a coordinate system based on a 'nominal arms length away' from the screen and then creates another set of units for mobile. I know there's a lot of smart people who contribute great data standards from the W3C, but when it came to presentation standards they either 1) completely forgot their linear algebra or 2) didn't bother to look at Postcript's coordinate system or both).

Some of us are reinventing the browser as it should have been written (with polyfills and shims), but this will take a while to get right. (For those that remember, Alan Kay originally said there should be no browser, just a code container, we are once again getting close to something he said decades before).

We understand that the W3C has set the expectation that everything bad on the web happens because of us devs not following their "standards" (even when alt changes to title changes to picture caption in as many years), but at some point it might be worth asking them "why are your presentation standards so inconsistent and hard to follow?"

Sincerely,

A webdev who is tired of cajoling CSS and JS to reinvent the same god-damned three column layout that should have worked in the 90's (oh wait, you didn't realize that Postscript predates the web? Yes, yes it did. So the W3C could have sought presentation layer experts of its time in drafting presentation standards, but didn't).

He can't really do that with the present approach. :)

Each 'drop' of rain is really a circle painted using the reflection scaled to the size of the drop. This approach is very fast, but won't scale well with odd-shaped drops and larger drops. With a small enough spherical drop, it's a good enough approximation for refraction.

With larger drops, you'd start to notice that the reflection isn't a refraction (i.e. the reflection is cutout in the shape of a circle, rather than truly refracted as in a drop of water).

Other approaches could be adding more expensive texture transforms, or WebGL + a refraction shader for bigger and/or non-spherical drops.

There is a very important reason client-side js apps are appearing: managing stateful apps over a stateless protocol means spending about half of your time and complexity budget dealing with state transfer. Js clients bring us back to the days of true application programming. They use REST and HATEOAS in a very natural way that most app servers have not. Maybe it's time to let the server side handle what it's good at?