Keep it respectful guys - while a lot of you are earning a shit load to peddle ads, this dude make some amazing original things and more importantly spent a huge portion of his life trying to help others get value from his thoughts and ideas.
Think about Eastern Front (which I haven't played) or Balance of Power (which I have, on the Amiga). There are tons of games that are similarly built, in whole or in part, on such mathematical models: SimCity, Rollercoaster Tycoon, the Civ series, any number of turn-based and real-time strategy games going back to the 8-bit era. Even RPGs use mathematical rules, with a handy dose of chance, to decide the outcome of different kinds of attack.
There's even a whole (I seem to remember) chapter in Stephen Hill's "Amiga Game Maker's Manual with AMOS Basic" on building "simulation games" using simple mathematical models.
Whilst I respect Chris Crawford's contribution to the video games industry I don't understand this perspective at all.
He has some interesting idea and is more than ready to share them with others, which is a respectable thing to do I agree. On the other hand, I find his models hilariously bad, e.g. :
> With Balance of Power, I could write a simple equation for the number of fighters who would join an insurgency against the government:
> `Fighters = Political Immaturity * Population * Previous Success of Insurgency`
> Here, `Political Immaturity` is a constant I defined for each country based on my estimate of how much people respected the rule of law.
Of course, but such simplifications are necessary given the limited power of typical 8- and 16-bit home computers of the time. And you don't need to do anything particularly advanced to create an engaging game, which Balance of Power is.
Of course you need to keep things simple on the hardware of that time. But still, I don't understand his complaint that nobody else followed in his footsteps; Europa Universalis has tons of calculations like that, all of them a lot more sophisticated than that. They're still massive simplifications of course, but I don't see how it's not a natural progression from his work in the 1980s.
> Europa Universalis has tons of calculations like that, all of them a lot more sophisticated than that.
It's incredible how many people keep missing the man's point. Almost making it for him. His point is the gaming industry is still completely filled with mindless NPCs and simple boolean interactions. He calls out God of War in another article as an extreme disappointment.
The fact that everyone here is saying his ideas have continued, but keep naming the same two or three games made by only a couple gaming companies proves how right he is. If you want any form of deep interactivity play a deep strategy game, anything else besides that in game design is still about as interactive as pacman.
His point is that after 35 years and literal orders of magnitude improvement in processing power, the average game is still modeled using incredibly simplistic logic and makes for empty interactions. And take a look at most any top selling game and it's true.
Your average squirrel in the park has more interesting behavior or interaction than most game characters. It's essentially just been "better graphics, bigger explosions" for three decades now. None of that precludes dynamic interactions.
Big game companies just make what sells. I don't see why anyone would expect that to change. It shouldn't surprise anyone that many games aren't very good; most of everything is crap, and games are no different. But the logic in the best games has absolutely progressed since the 1980s, and even many (though not all) FPS games put quite a bit of effort into making their game characters move and act in a believable way. Far more than they did 34 years ago.
Though there's undoubtedly still plenty of room for improvement. In terms of how smart computer characters move and act, I think Robin Hood, the Legend of Sherwood (2002) still stands out: there, when a guard spots you, they first become curious and come check you out. When they're sure they've seen you, they raise the alarm and attack you, and other guards that hear them, join them. When a guard finds a dead guard, they look for their boss, who then organises a search party. It's all very logical, and it results in a very exciting isometric stealth game. Especially the fact that the guards cooperate, but need to communicate over credible distances first, makes the whole thing work very well. There may well have been other games that work like this; I don't pretend to know most games, but I've never played anything else quite like it.
> spent a huge portion of his life trying to help others get value from his thoughts and ideas.
Did he really? Or did he spend that time satisfying his own ego and tell himself it was for the sake of helping others? Certainly it sounds like he managed less actual helping others than those of us "earning a shit load to peddle ads".
This guy seems to try to bluntly tell it like it is. He's completely wrong, but hopefully he can appreciate the same sort of blunt feedback from others.
Some tier-A mathematicians working on some pretty fucking cool problems in online decision making and machine learning, or someone who writes shit like:
"Young people these days, I am told, are illiterate and cannot understand the written word. They can learn only from video. So should I speak to them in the language they understand?
Yes, I probably am a genius—but the issue is meaningless."
I have read most of the stuff he has written and it is 95% fluff and 5% ideas. Lots of promises and self-promoting. Very little actual value. In contrast, I have also read Einstein’s book about relativity. The difference is like night and day. Einstein: 100% mind blowing ideas. 0% self-promoting.
Me too! I got stuck there because taxis weren't running to the airport due to snow. Had a rad time... everything was covered in snow, not a car on the road. Apparently the locals hadn't seen anything like it, so maybe a freak one. This was late 2000's, can't remember exactly when
We had a good snow last month - about 6 inches. But yes that kind of thing is so exceedingly rare (about once every 10 years) that the entire city economy basically grinds to a halt so everyone can go outside and play in the snow. The last time that happened was probably the incident you are describing.
Very interesting. I'm currently desiging and building a system which has a separate MCU just for timing accurate stuff rather than having the burdon of realtime kernel stuff, but I never considered just dedicating a core. Then I could also use that specifically to handle some IO queues too perhaps, so it could do double duty and not necessarily be wasteful. Thanks... now I need to go figure out why I either didn't consider that - or perhaps I did and discarded it for some reason beyond me right now. Hmm... thought provoking post of the day for me
I'm sure this will be buried etc, but just something to pass on. I spend a lot of time in small planes doing aerial surveying work with equipment I make. The pilot i've flown with the most spent his whole career flying and training others to fly A-10s. We had so much time (100's of hours) just sitting in a cessna together I got to ask tons of questions and hear lots of stories.
One of my favourites was just peacetime stuff when they flew non-stop from their base in Germany back to the US, refueling on the way. Just think about that - you're a pilot used to doing close air support short missions and now you're off on what in only a few decades before would have been an adventure on the scale of the great explorers.
He would regularily comment on how good the missile launch system is... essentially it chose the right time to launch based on the pitch/speed/location etc of the plane. He mentioned it enough times it must have been pretty special.
When I asked him if it was difficult to fly, he said that other jets he flew were more difficult (flame outs etc), but it also wasn't easy.
In 30 years flying them the only missile he ever launched (or maybe only missile of a certain type... not sure), was for training and cost $1m+. Everyone at some point in their training got to fire one at a dummy tank. He said the accuracy was amazing... he hit it bang on - mostly due to the targetting tech he was praising rather than his skill. He did mention that the $1m price tag was misleading because they expire and use missiles which if not used would be scrapped anyway. Or something close to that - this was 4-5 years ago my memory is a little hazy.
And the gun. Well... this guy is a republican voter (which was always funny as I'm way left of Sanders), with a heart of gold but had some interesting theories about the best use of the A10 related to Trumps border wall. He said they do so much shooting out in the desert, they could just relocate all their practice along the border with mexico, not spend anything extra than they are now and no one would dare go near it. I'm not sure how much of that was in jest or how serious he was. Thats abhorrent to me but all good we all get to have our views.
He has a model of an A10 on his desk which was gifted to him when he stopped flying them, and a big picture of himself climbing into one on the wall back when he was lean and handsome and hadn't put on his old-timer weight. My first flight simulator was A-10 on the Commodore 64, and it literally set the path to me ending up working with him.... my interest in aviation, cameras, computers etc. So both that photo and the model on his desk felt really special to me in a way that I can't really explain.
And of course being a nieve computer guy, I had to ask 'the question'. Did he knowingly kill anyone. He didn't answer.
and people who say that saturated fat causes heart disease are like people who say we should stop driving cars because they have been shown to raise death rates. there is no randomized trial that shows saturated fat is harmful. there is no study where people were assembled, divided randomly into fat + and fat - groups, kept under supervision and only allowed to eat the meals provided by the study (without being excluded from the study). it is so blindingly simple and yet nobody does it. meanwhile, our ancestors ate nothing but meat for millions of years.
> meanwhile, our ancestors ate nothing but meat for millions of years
Our ancestors ate almost entirely plants. Even we modern humans only recently started getting a significant proportion of our caleries from meat/animal fat.
Now we have cardiovascular diseases being the main cause of death and one of the leading causes of poor quality life in peoples final years. It's unfortunate
Doing the same thing but on CUDA cores. I am evaluating it for our needs and the quality of the whole SDK is outstanding. Great doco and testing, and performance is amazing. And thats not over 12 cores, it's over hundreds or thousands.
Ruby has definitely helped me get through some rough and tight spots. So many things are easily able to bum me out, while Ruby goes out of its way to make me happy.
> Welcome home. Things are going to be fine. Don't worry about nonsense. Just `:chill`
A beloved safety blanket that makes it easy and fun to do boring everyday tasks.
What are your thoughts about it being the 7th most dreaded language on Stack Overflow's 2020 developer survey? I've never programmed in Ruby, but it seems attractive to me.
I honestly cannot believe that this is a solid metric. I believe the question, or their answers are poorly parsed.
I presume a lot of the dread is really about Rails. And the rest partly hearsay of the slow performance of Ruby.
Rails is, to me, a blessing, but also a terrible framework. It helps to rapidly ship products. Just cobble some gems together in a controller or two, mix a gem or three into your models and you have a demo. A rapid Proof of Concept. But also a product that is practically unmaintainable. I've been doing Rails from its very beginning, solving this (trying to) has been my primary job for over seven years now.
And performance? Yes Ruby is slow. But the speed of the language is unmeasurable in, I daresay, the vast majority of the projects of people who tell you it is too slow.
That legacy mysql setup, this poorly evolved domain model, or that badly integrated external API is almost always the thing making it slow. The ms of Ruby handling that JSON to CSV conversion then is practically unmeasurable.
Rust is not going to speed up those 3000ms spend in that ugly SQL query. Go's multithreading is not going to solve the slow API which you call thrice per minute. And Java is not magically making the tangle of classes, jobs, callbacks, listeners and whatnot dissapear.
Rails is alright. It's just a great scapegoat for bad teams working under impossible deadlines: "Our code is unmaintainable because Rails! We need 1 year to rewrite it in Go/Elixir/Java". I mean, because Rails has a flat structure you couldn't ever take the time to reactor that piece of crap code you wrote for 2 years? really? You didn't notice a model stopped making sense or growing in complexity?
I see the same criticism with PHP. It's perfectly fine, stop blaming the tool.
Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns.
On contrary: often it encourages bad practices through "defacto" standard gems, or by making "the wrong choice" easier than "the proper design pattern". A "concern" is a simple way to turn a 800-lines controller into four 300 lines modules that amount to the same ball-of-mud, for example. (Concerns have great use-cases, but most often it is not the solution to your problem). Rails offers things like `try(:foo)` to quickly solve that equivalent of the "null-pointer"- exception, without forcing the developers to dive and in and solve the reason why it is nil, or solve it with some design pattern (adapters, null-pattern etc) either: just keep sprinkling `try()` keeps it rattling along too. Somewhat.
So, yes: lack of proper design and architecture is the real problem behind those "ball-of-mud" rails projects.
But Rails' lack of training-wheels and the ease at which to make the wrong choices, really doesn't help teams aim at proper design and archicture either.
> Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns.
I think this is only half true. Rails certainly forces very little on you - but has lots of documentation and helping hands pushing you towards tdd - and it has fairly powerful and simple tools to help with data modeling - as long as your data can fit reasonably in the ActiveRecord pattern.
More complex subsystems can be split out into rails engines or services.
All that said,it is indeed easy, without some discipline, to roll out complected controllers and views.
But I don't think it's fair to say that rails the framework via structure or its official guides, encourages that.
Quite the opposite.
As for "try" (now for a long time largely subsumed by ruby's built in &-operator) - that can be helpful where appropriate, like with handling input,and occasionally with explicitly optional relationships and nullable values. But of course NULLs should normally be avoided, and the database should be leveraged to ensure data integrity. And rails allow you to do that.
Rails has a flat structure, it has no knowledge how big your project will become. For many, many code bases this is good enough. Look at Gitlab, which is quite big.
If you need more structure there are many design patterns you can follow and introduce into your codebase.
I like their UI just fine. Speed, smoothness, never had much of a problem. And the amounts of features they were able to come up with the last few years is pretty impressive.
In terms of features I quite like GitLab as well. I just think it's time they rewrote it in something much faster than Rails.
I have literally never used a fast GitLab instance. Anecdotal evidence, I am aware. I'd still venture out to claim this says something about the average speed of your average GitLab installation though.
Hmm don't see any rewrite in their cards though...they're pretty much gonna ride this thing with Ruby. If Shopify did it with their monster scale I bet they can as well.
On the nulls bit, in a context where nil is a legitimate value, my team's policy is to use the ampersand operator. To be honest this is preferable because it clutters up code the least. I don't think we use a single try() anywhere, even before I used ampersands it was always `blah_blah unless x.nil?` etc etc
There are legitimate cases for `nil`, but far less than most people allow.
What does "user.last_login_at == nil" mean? `NoMethodError `to_human_date` for `nil` in email.erb. "Quick! lets fix that with a `try(:last_login_at, "Never")`: if nil, it means the user never logged in.
You now, without proper thought, you introduced a business meaning to a missing value. Adding tight coupling, slowly painting yourself in a corner. How does this translate to "Could you give me a CSV with all users that never logged in"?
Maybe you did mean to assign such domain-meaning to "last_login_at == nil", but then it is far better to explicitely do this. E.g. a `NeverLoggedInUser` subclass, a method on the model `never_logged_in?` an explicit flag in the database, or maybe even a special table "inactive_users" that holds these. All depending on domain-meanings, discussions, use-cases and thought. This is always a lot more work than just throwing another `try` at the bug. Rails "rewards" the bad choice, and somewhat opposes the proper solution.
Rails makes it easy to prototype and rapidly move forward: those are good features. But often you should, instead, be forced to halt for a second. To push you towards the whiteboard. Being able to throw in a quick `try` here, or a `sort(last_logged_in: :desc)` with another `where.not(last_logged_in: nil)` there, and so on, are a blessing when quickly moving forward. But they will haunt you in the future.
Balancing that is hard, regardless of framework, but Rails' features balance towards the "moving fast" a bit too often in my liking. Esp. because it rewards that team-member who "Gets stuff done" by abusing those "quickfixes", while leaving the project with ever more technical debt etc.
Having worked and working with rails projects spanning ruby 1.9 through 2.4 and rails 3.2, 4.1, 4.2 and 5.2 - the major issue I've seen with legacy rails is how difficult it is to keep views refactored and seperateted into widgets. Some teams seem to blame erb for this and run towards various different template dsls like haml (equivalent to writing a template language for php, which already is a template language, because the team can't keep views/templates simple).
Fat/smart models help - but the old/standard tools in rails (helpers and partials) INMHO is poor tooling for the "view" layer - and this just gets worse with Javascript in the mix.
Another option is of course to just use rails as an api server, and do the front end in react/vue etc. Although, at that point, you might be better off just using postgraphile or hasura.
The other real problem I see in some of our projects, is developers simply not trying to learn minimal best practices (just reading a few paragraphs on rails guides...). And that leads to many awkward choices, a lot of re-inventing subsystems that already exist in rails (because developers didn't have a look before coding up a quick fix) - and few tests and poor testability. But those strike me as much more cases of people "holding it wrong" than rails being the problem.
Finally, I think there's still some issues in rails 6 with asset handling - but overall rails 6 seems like a comprehensive, solid and easy to use framework.
> But those strike me as much more cases of people "holding it wrong" than rails being the problem.
My idea exactly.
To stretch that analogy: Rails has guides, books and neat API documentation explaining how you should "hold it properly" (and when not to etc.). But it also lacks "notches", "crossbeams" or "ridges" that help people "hold it properly" on a daily basis.
Well, what you said would be true if management was sympathetic to the argument of "the language and framework we are using no longer serves the project well, so let's rewrite". Since they are not, projects are, 99% of the time, stuck with their first choice of language / framework for life.
What I meant was you can take a messy Rails monolith and do a million things to improve it (including breaking it into smaller independent services if that's your thing). Rewriting in another language is the last thing I would do if the project is big.
Ruby isn't new or novel anymore, and is a relatively small niche. Learning it properly takes time and effort - hence the "dread". I'm pretty sure 10 years ago no one dreaded Ruby yet the language was almost identical to what it is now. So I think it speaks less about languages per se and more about hype cycles and job markets.
There's a saying that Ruby gives "Every toddler a chainsaw" (https://codefol.io/posts/ruby-python-and-freedom/). You can use it and it's metaprogramming to write some really elegant APIs. You can also write entirely the wrong abstractions, and it will not stop you. You can even extract private variables from lambdas if you're willing.
Now, imagine that in the hands of someone with poor taste, or, even, just rather different taste than yours.
Not a big fan of Ruby (okay, with 3.0 I might become a fan again!) but to be fair, these SO surveys are asking really weird questions that appeal much more to emotion than to reason.
