Live data from Hacker News

Fun vs. Computer Science (2016)

prog21.dadgum.com

41–50 of 184 posts

Re: Fun vs. Computer Science (2016)

#41
>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 way of testing everything.

It will be so great that people will be able to make even more complex games, and have them not crash.

Re: Fun vs. Computer Science (2016)

#42
post #21

Earlier quoted context omitted.

Great question! To make things even more annoying - C doesn't have namespaces. So people are forced to write long names like "my_struct_hash_map_t" everywhere, which makes all modern C code look like wall of text (compare too older style code "mshm_t*a = hmalloc()"). To answer honestly - I'm asking myself very pragmatic question: "do I really need a generic code?" much more often compare to C++. In game development C…

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.

I think that's why Go is so popular right now. I find the language kind of depressing from a PLT perspective, but it was built taking into account practical requirements such as fast compile times, a standard formatting tool, ease of deployment, etc, which makes it a very good system.

Re: Fun vs. Computer Science (2016)

#43

I 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.…

One very common complaint I've heard about Haskell is slow compile times, see this discussion for example with a bunch of GHC developers: https://www.reddit.com/r/haskell/comments/45q90s/is_anything...

It's funny how when someone describes their own experience, you tell them they're wrong. Are you claiming the GP didn't actually experience fast reloads?

Initial compiles of some Haskell libraries that essentially do exponential inlining (cough vector-algorithms cough) can take a long time. An incremental non-optimized compile of a small change to a project with a good module structure takes a couple seconds.

The GHC devs are correct that it has been slowing down and are putting a lot of effort into getting that speed back. But it's not at the level of "rebuilding my project takes hours" that you frequently get with some build systems.

Re: Fun vs. Computer Science (2016)

#44
post #29
post #7

I 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…

TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that one test until it succeeds. After I have individual parts working, I will integrate everything, which again will just be another integration test run from the IDE. I realize this isn't always possible, and is probably easier to do in a managed language, but yo…

Despite being downvoted, this assertion about TDD is true. It can provide a very interactive experience when programming, even with languages with little natural interactivity. But you have to know how to set up the tests.

Re: Fun vs. Computer Science (2016)

#45

I 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.…

One very common complaint I've heard about Haskell is slow compile times, see this discussion for example with a bunch of GHC developers: https://www.reddit.com/r/haskell/comments/45q90s/is_anything...

That discussion is over a year and a half old.

Re: Fun vs. Computer Science (2016)

#46
> It's about being able to implement your ideas.

This is where the choice of language might help or hinder you. One language might take longer to implement it or be more prone to bugs.

The question of whether or not your ideas turn out to be fun is completely orthogonal.

Re: Fun vs. Computer Science (2016)

#47
post #38
post #7

I 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".

So is python, which is a much nicer language.

Re: Fun vs. Computer Science (2016)

#48
post #18

I think it might be possible to get the benefits of static type checking while still allowing interactive modifications, but most current type systems don't lend themselves to that. While it would be possible to replace any value by another of the same type (e.g. redefining a function without changing the signature), I'm not aware of any statically checked language with a REPL that allows that. When I'm playing aroun…

Not sure about Haskell (what I know about the compilation model makes it seem more difficult), but in a typical Java environment (including an IDE remote debugging tomcat/jetty, for instance), the debugger will hot swap changes that are just to method bodies.

The sad part is that this encourages bad development practices because piling on nested loops doesn't require bouncing the server, while properly factored code does.

There are tools like JRebel that are supposed to fix this, but I haven't used them.

Re: Fun vs. Computer Science (2016)

#49
post #28

I 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.…

It's not a dichotomy at all. Type systems etc are obviously there to make it easier, faster and safer to build and maintain your code. I'm much more productive in Swift than I ever was in objc. The one case where it might make sense to through CS out of the window is if you're building something very small that you are sure you will never reuse or even look at again. And even then I'm not sure it is faster to be slop…

*throw (not through)

Re: Fun vs. Computer Science (2016)

#50
post #34

Earlier quoted context omitted.

Can you expand on what is meant by algorithms and computing, and what you mean that computers mostly do instead?

The skill of programming is really about translating tasks that are semantically meaningful to humans (ie making a user friendly online booking site for a hotel) into "meaningless" instructions that can be computed by a turing complete machine. That's very different from, say, deriving a faster partition algorithm by using half-swaps instead of full swaps (as demonstrated by Andrei Alexandrescu last year).

But aren't all forms of engineering about translating semantically meaningful tasks into {problem-domain}? What makes software different?
Post reply on HN