The thing is that most people working in academic computer science are not very good programmers. They don't have to be, as their main duty is not to produce working code, but to produce publishable papers. Of course there are very good computer scientists who are also great programmers, and this is where the practically relevant research is produced.
Fun vs. Computer Science (2016)
51–60 of 184 posts
Re: Fun vs. Computer Science (2016)
#52I'm rather late to this party, but it is so nice using C# with "Edit and Continue". Program hit an exception? No problem! We'll just make that didn't happen(+), move the next line of execution back a bit, edit some variables, put the correct code in, and carry on. Of course, sometimes E&C just doesn't work for mysterious reasons of its own. (*) English unsurprisingly lacks an acausal past tense to describe doing some…
How about "we'll just undo that"?
Re: Fun vs. Computer Science (2016)
#53Flutter ( http://flutter.io ) strikes an interesting balance here by (1) allowing just-in-time compiled, state-preserving "hot-reloading" during interactive development and (2) supporting optimized deployment using classical ahead-of-time compilation to native code. Disclaimer: I work on the team at Google that builds the underlying language platform for Flutter.
I have been trying out Flutter over the past week or so and so far it really has delivered on high speed build-edit loops. I've already gotten in the habit of improving layouts while the app is running, it's really a great experience.
Android build times have improved a lot over the past few years but this is a whole next level experience.
Re: Fun vs. Computer Science (2016)
#54I have happily traded working in a nice language with slow iteration times to working in a lousy language with very, very fast turnaround. My favorite extreme example was the time I used a super fast 6502 assembler environment that would do the "change a line of code and get the target running" cycle in a couple of seconds. This kind of interaction is magical . You're still writing kind of crappy assembly language, b…
> The PHP "builds" as fast as I can refresh a browser page JavaScript is just as fast, or faster. That's probably an important reason why it's "eating the world".
I agree that JavaScript is fast - but we've ruined that in a lot of places by throwing in things like code genertion, compilation, builds, and other nasty words. The turnaround for the last React&Node program I had the displeasure of working with was on average 30 seconds.
PHP - for all its faults - does not suffer from these kinds of recompilation issues, yet can be optionally pre-compiled for added speed when you do go to production.
Re: Fun vs. Computer Science (2016)
#55Earlier quoted context omitted.
There's a bizarre lack of interest in CS in the psychology of usable systems - either for developers or for users - which takes into account practical requirements like cycle time. A lot of CS seems to be story-telling: "This feature makes language X better/worse, because it just does, obviously" with no independent testing or peer review of language productivity and robustness in real work environments.
Well then, so much for it being Computer Science ...
As-is, CS really is much closer to a branch of mathematics than a science.
Re: Fun vs. Computer Science (2016)
#56Worth noting that "fun" in this case means player fun, not programmer fun. My productivity and my enjoyment of game development in C++ are secondary to the user's enjoyment of the finished game, and this is where the author's point gets more interesting and valuable. There are a lot of comments here already talking about fun, code safety, and productivity from the programmer's point of view, which IMO misses the most important part.
As a game programmer, building systems with fast turnaround times is more valuable to the artists and designers in the studio than for me personally. And the value in the artists and designers and programmers all having fast turnaround time is in being able to make a game that's more fun for the consumers.
Re: Fun vs. Computer Science (2016)
#57I feel like this is a false dichotomy: you can have a fast iteration cycle, and have statically checked guarantees. I've worked in Haskell for 7 years and had exactly this. I could load my entire app in GHCi, make changes, reload and test. Now I'm working in Java and in IntelliJ I can have something similar with hot-swap. And in the browser with typescript I have a strong type-system and can reload my app in seconds.…
This has not been my experience with strongly and statically typed systems. The biggest problem is the coding is not fast; especially if you make a change that requires "shaking the tree". Turnaround to me is as much about the code you write as it is the results you get from that code.
For example, I start my program thinking that I need a duck for all of my various waterfowl systems. However, four days into the coding process, I realize I need to allow for an ugly duckling to be passed around as well. Now I have four days worth of code to comb through and re-type. I could just use a refactoring tool to change all of the existing 'duck' types, but some of that code actually does need a duck, and won't work with an ugly duckling. So I have to come up with a more abstract type which can encompass both an ugly duckling and a duck, and refactor that into my program.
Eventually my code will be correct again, at least until I realize that a platypus needs to be included into my now-renamed aquatic_ecosystem as well.
The nice thing about strong and dynamically typed systems - I just start treating the incoming object as what I need it to be. No error chasing, no wading through four days worth of code. Yes, I'm more likely to have incorrect code, and it's probably going to show up while the code is running, and not before. Many times, that's a tradeoff I'm willing to accept.
My ideal system? I don't think at all about types. I just write code, and the (still fast) compiler will tell me when I'm passing something that doesn't quack to a function which expects quacks.
Re: Fun vs. Computer Science (2016)
#58The most fun language (having tried lots of them) I put my hands on is Julia, I just love it. You can do so much with such little effort and it can be optimized to almost match the speed of C.
The 2 main downsides is the lack of proper interfaces and object.method() notation, which is sometimes more readable.
Re: Fun vs. Computer Science (2016)
#59I think, to some degree, the idea that drives strongly typed, theorem proved languages is a bit different than what most people think of when coding. A large set of people in that community want to derive algorithms mathematically, using a deductive or proof based process, as in math. Iterative development conflicts with a top down form of development, and also conflicts with the safety oriented culture of strong typ…
One thing to remember - the domain under discussion in the article is gaming. There's little maintenance typically involved with games.
There's more today than there was yesterday, but it's still not a system expected to be built, maintained, and extended for decades.
Re: Fun vs. Computer Science (2016)
#60>Does choosing C++14 over C++11 mean the resulting game is more fun? Even though I agree with the main point of the article, I have to point out that when a game doesn't crash every hour, it's definitely more fun. Few examples of games that do crash: many games in the Elder Scrolls series, Fallout 3 (and New Vegas), Dwarf Fortress. Games that are undeniably complex and emergent in such ways that the coders have no wa…
The article agrees.
> A better argument is that some technologies may result in the game being more stable and reliable. Those two terms should be a prerequisite to fun [...]