Live data from Hacker News

Fun vs. Computer Science (2016)

prog21.dadgum.com

11–20 of 184 posts

Re: Fun vs. Computer Science (2016)

#11
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…

One of the reasons why I switched from C++ to C professionally (I do C for living) was build times: previously kind of big casual game took 5-10 minutes to compile and around 10-20 sec incremental build, and now my C project takes 5 second to compile from scratch and around 1 second to do incremental changes.

Another reason being that I don't need to waste time discussing and arguing which OOP patterns to use - in C it more or less fixed how you write code. Of course one can go extra mile and reinvent VTable and Dependency Injection, but it feels all foreign to C.

So maybe give C a try, it's amazingly fast to compile and link, yet you feel almost at home after C++.

Re: Fun vs. Computer Science (2016)

#12
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…

Is there a way to write the changes in the REPL back to source file, or do I have to copy? I am wondering since trying out Clojure.

A better pattern is to use your editor as the REPL via SLIME or vim-fireplace or similar. Basically:

1. Headless server like nREPL for Clojure

2. Code editor that can send chunks of text to the headless repl and receive the output. Emacs and neovim (with its terminal) are pretty good at this. You can use commands to send the surrounding s-expression, paragraph, etc.

3. Ta da! Your text is already in your source file.

Re: Fun vs. Computer Science (2016)

#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 something that changes an event that has already happened.

Re: Fun vs. Computer Science (2016)

#14
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…

I think "We'll just make that not have happened..." would be correct English, but your version, though clumsy, is more evocative of what you actually meant. It's coming into more common usage, too.

Re: Fun vs. Computer Science (2016)

#15
post #6

I feel it's the other way round.. Everyone is advocating Javascript, python etc. JS webapps are more and more developed directly in the browser in the dev console, CSS interactively modified to directly see the results. But this also lead us to code coverage abominations where people write hundreds of tests for manually checking input types that otherwise might crash the thing after two days running because that hash…

Yes, I don't think type systems (or, in general, "computer science-y stuff") are the enemy here. I do at least wonder about some of the stuff that passes for "best practices" nowadays: CI tools sound like a good idea on the surface, but can serve to (partially) hide complex build and deployment processes where once someone might have just typed make. Automated tests of awkward corner cases can be pretty valuable, but easily lead to test suites that take minutes (or worse...) to run on every build. I don't really know how best to get the good without the bad, but giving at least some weight to the "sense of fun" stuff sounds like a pretty good starting point.

Re: Fun vs. Computer Science (2016)

#16
post #11
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…

One of the reasons why I switched from C++ to C professionally (I do C for living) was build times: previously kind of big casual game took 5-10 minutes to compile and around 10-20 sec incremental build, and now my C project takes 5 second to compile from scratch and around 1 second to do incremental changes. Another reason being that I don't need to waste time discussing and arguing which OOP patterns to use - in C…

How do you cope with the lack of template containers? That's the big thing I miss in C.

Re: Fun vs. Computer Science (2016)

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

I agree that it's easy to build a slow, batch based build system and just tell people that's how it is. Fast iteration is important and requires effort to keep working. It might even be more important than a static type system, at least for some apps. But you can have both.

Re: Fun vs. Computer Science (2016)

#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 around in the Haskell REPL, redefining a function requires also redefining all other functions that use it, and that's a chore that isn't even required by the type system.

Other modifications are likely to break static checks, e.g. adding a new case to a sum type would invalidate exhaustiveness checking (and thus probably a bunch of compiler optimizations), so no standard type system would allow it. But having a check that makes sure you handle the added case everywhere would actually be nice to have, especially when it can tell you interactively where you need to add more code.

The major hurdle to altering a running program without violating type safety is the fact that you can't just check the original program and the modified version for internal consistency, you also have to ensure that old code that's still running won't be confused when it calls new code and gets an unexpected return value. In the case of adding to a sum type, you could compile in a fall-through case for all pattern matches, and then patch in the new handler code.

For even larger changes, like completely replacing the return type of a function, it might be necessary to specifically engineer the type system such that it can support this case. 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.

Re: Fun vs. Computer Science (2016)

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

Re: Fun vs. Computer Science (2016)

#20
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…

> to working in a lousy language with very, very fast turnaround. [...] The PHP "builds" as fast as I can refresh a browser page.

This observation ("workflow") was one of the 3 bullet points outlined by Keith Adams' 2013 presentation "Taking PHP Seriously".[1][2]

(KA's presentation was partially a response to 2012 "PHP a Fractal of Bad Design".[3])

Basically, the horrendous inconsistencies and flaws outlined in "PHP Fractal Bad" can be true ... but simultaneously be overshadowed by "workflow" benefits.

[1] starting with slide #14 of "Adams-TakingPHPSeriously.pdf" : https://github.com/strangeloop/StrangeLoop2013/tree/master/s...

[2] 4 previous HN threads: https://hn.algolia.com/?query=php%20seriously&sort=byPopular...

[3] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Post reply on HN