Fun vs. Computer Science (2016)
prog21.dadgum.com
Fun vs. Computer Science (2016)
1–10 of 184 posts
Re: Fun vs. Computer Science (2016)
#2Agree 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 10 to 30 minutes.
Lisp championed interactivity, it invented dynamic programming for that sole purpose. The idea is that you morph a running program into shape, molding it like you would clay.
The first thing you do when writing in a Lisp like Clojure is run your program. In most other languages, running your program happens much later, and much less frequently, and it can actually be quite challenging to run.
Re: Fun vs. Computer Science (2016)
#3Yes, yes, and yes.
I'd go even further and claim that productivity is the ultimate currency in programming, because you can convert it into pretty much anything and everything else. Better quality, better performance, better UI. Of course, there is no guarantee that you will actually do that.
Reaping these benefits does mean that you need to constantly work at improving the code, "if it ain't broke don't fix it" leads to entropy, and so does being afraid to make fundamental improvements due to lack of test coverage.
Re: Fun vs. Computer Science (2016)
#4Agree 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 testing?
How is the actual work flow you use when molding your app?
Re: Fun vs. Computer Science (2016)
#5Agree 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…
With a good IDE with an integrated debugger Python and its ilk, and even Java, are like clay. PyCharm, IntelliJ, and their siblings.
Re: Fun vs. Computer Science (2016)
#6I 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 hashtag less of lists of objects contained a string instead of a float.
Is that fun?
In gaming Unity3d embraces this interactivity by modifying more or less everything directly while the game is running. The unreal engine blueprints show data flows live etc.
In technical sciences there was always Matlab with its interactive mode of development. We have similar technology in data science with ipython, Spyder, jupyter notebooks etc.
Actually I'm seeing more interactivity than good type systems out there. Elm, Haskell & co is something you find advocated in internet forums but rarely in companies.
(and as the author mentioned - those two actually don't have to be exclusive)
Re: Fun vs. Computer Science (2016)
#7I 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, but it almost doesn't matter. Things just flow.
On the other extreme: A large component of me deciding to quit a job was the fact that a build of the product took four hours. And the build was typically broken. So: Arrive in the morning, sync, wait all morning for the build to fail. Do another cycle after lunch: fail. Go home, repeat for weeks. (Add to this: Managers who refused to buy decent development machines, people who kept checking in busted code and making things worse, and a crushing schedule. Who needs that?)
These days I'm do a lot of C++, and some PHP. The C++ projects take a few minutes to build, which isn't great, but it's survivable. The PHP "builds" as fast as I can refresh a browser page. And as much as it pains me, on most days, when I grit my teeth and get honest about it, I'm more productive in PHP. And I despise PHP.
I learned LISP early on in my career; wrote a few LISP interpreters, goggled at the majesty of LISP machines, read all that I could. But I've never shipped a significant project in LISP, nor am I likely to. And the Newton actually flipped from a LISP (well, OOPy-Scheme) implementation language to C++ in order to ship. I'm wondering if there is some law of human nature at work: You can have elegance and comfort or you can have a product. I sure hope I'm wrong.
Re: Fun vs. Computer Science (2016)
#8Fighting with a bad technology stack definitely takes time away from the domain, where "the fighting" is different for everyone. One should be in a state of flow during dev, game or anything. So the tools that enable you to get there are the right tools.
Does correctly implementing a composable state machine and effects system mean the game is more fun? Usually.
This essay is full of question begging and false dichotomies.
Re: Fun vs. Computer Science (2016)
#9Agree 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.
Re: Fun vs. Computer Science (2016)
#10Agree 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.
With a set-up like Cider in Emacs (and I wouldn't be surprised if Cursive with IntelliJ has something similar), you can write code in a file and send it to the repl for evaluation.[0] This is a common method of development which accomplishes what you describe: code in a source file, evaluation in the repl.
[0]: https://cider.readthedocs.io/en/latest/interactive_programmi...