Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun vs. Computer Science (2016)

prog21.dadgum.com

Post reply on HN
Print view View original

61–70 of 184 posts

Re: Fun vs. Computer Science (2016)

#61

Post by kbutler »

pjc50 wrote: post #13

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

"We'll make _it_so_ that didn't happen" sounds perfectly natural to me.

Or "change it so..."

We change [history/state of the world] to not include that event.

Re: Fun vs. Computer Science (2016)

#62

Post by dahart »

mmirate wrote: post #35
TheOtherHobbes wrote: post #31

Earlier 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 ...

Since computers are built by people for people, it does seem like we're missing the most important and difficult science in favor of doing the science that's easy to do. It's easy to reason about how a system that I designed will perform. It's hard to answer the questions of how our technology choices affect other people. It would be great if science could help us design high quality systems with a limited budget, or establish a theory around whether designing any given system will improve someone's life. It would be pretty dang useful if we had some formal scientific results around what makes a game fun, or more generally what makes software pleasant to use and productive.

Re: Fun vs. Computer Science (2016)

#63

Post by falcolas »

jfries wrote: post #4
didibus wrote: post #2

Agree whole heartedly! That's why my favorite language is Clojure. That interactivity, instant feedback, seeing the program running as you are tweeking it, its a bliss to use and it creates better more functional software. Imagine playing music as you hear it when trying to come up with a good melody. Now imagine not playing it, but composing it on music sheets instead, and occasionaly playing what you've got every 1…

When showing off Clojure the application is often molded while running by patching it via the repl. But what I don't understand is if you can actually develop real programs like that? Surely even in Clojure code there are lots of dependencies so you can't just change one place in isolation. And I also guess that changes done on the repl aren't actually saved for the next time you run your app? And how do you do testi…

The trick with some of these runtimes (I don't know if Clojure does this, just noting that the paradigm exists) is that the state of the runtime is not lost when going from development to production.

The entire state of the program, including the code and the globals in memory, is preserved, and simply spun up in a different environment. This tripped me up for some time with Smalltalk - I didn't understand this.

It's the same with many lisps - you can frequently get a REPL directly inside a running program, and query/change the objects (including code) that is running. This was used to great effect in fixing the Deep Space 1 probe while it was 100 million miles away from Earth.

https://en.wikipedia.org/wiki/Deep_Space_1

Re: Fun vs. Computer Science (2016)

#64

Post by falcolas »

bambax wrote: post #39

Maintainability is also important for "fun". If you can't touch the code for fear of breaking something, fixing bugs takes forever and new features / levels / versions never happen.

Games are rather infrequently maintained. There may be a few early patches, but after a year or so, the game is left as-is.

As a great (yet personally disappointing) example, I give you Mass Effect: Andromeda. No more patches or content will be released for the single player game only 5 months after its launch.

Different needs for different domains.

Re: Fun vs. Computer Science (2016)

#65

Post by catnaroek »

yorwba wrote: 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…

> Ideally, it would support almost all modifications that work in a dynamically typed language, while still preventing anything that would take the program into an inconsistent state.

This is impossible. Data structures have these little things called “invariants” that require proof to be established. In statically typed languages, abstract data types are used to prevent users from breaking these invariants, by making the representation invisible to anyone but the implementor.

If the data structure underlying an abstract data type can be modified anytime, then every time you patch your program, you would have to check two things:

(0) That the new data structure respects every invariant relied upon by other code.

(1) That either the new data structure is compatible with the old one (which is often not the case), or there are no reachable instances of the old data structure in memory.

This is an even bigger pain in the ass than just stopping the program and fixing it.

Re: Fun vs. Computer Science (2016)

#66

Post by mbrock »

falcolas wrote: post #57
hesselink wrote: post #17

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

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

A lot of people who stick with expressive static type systems find the process of fixing type errors quite enjoyable. I really like the experience -- I can go really fast confidently.

GHC does let you defer type errors until runtime but I never want to...

Re: Fun vs. Computer Science (2016)

#67

Post by caseymarquis »

falcolas wrote: post #54
bambax wrote: post #38

Earlier quoted context omitted.

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

I don't use backend js, but things like webpack-dev-server which on file save do an incremental recompile and then hot reload have made this a non issue on the frontend for me. Not sure if this applies to your use case, but figured it couldn't hurt to offer a partial solution.

Re: Fun vs. Computer Science (2016)

#68

Post by Jhsto »

kasperl wrote: post #19

Flutter ( 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.

Thank you for your work on Flutter! I tinker with it during weekends like this and despite it being my first go at mobile development, I feel productive programming in it.

Re: Fun vs. Computer Science (2016)

#69

Post by falcolas »

mbrock wrote: post #66
falcolas wrote: post #57

Earlier quoted context omitted.

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

A lot of people who stick with expressive static type systems find the process of fixing type errors quite enjoyable. I really like the experience -- I can go really fast confidently. GHC does let you defer type errors until runtime but I never want to...

> find the process of fixing type errors quite enjoyable

I, myself, would rather be creating new functionality than fixing a litany of type errors. In fact, I'd rather go to a meeting than change several hundred instances of 'duck' to 'waterfowl', 'avian', and 'ugly_duck' (knowing that I'll probably have to go back and change it again later).

Different strokes for different folks, I guess.

Re: Fun vs. Computer Science (2016)

#70

Post by breatheoften »

jnbiche wrote: post #44
ece wrote: post #29

Earlier quoted context omitted.

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.

I'm enjoying wallabyjs with jest and vscode. It's quite fun having feedback from test execution always available in the IDE.

I don't have a long build step for my codebase (compiling typescript just takes a few seconds and incremental is instant) -- but I do avoid lengthy deployment cycles -- deploying code to aws lambda takes quite awhile.

Post reply on HN