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

21–30 of 184 posts

Re: Fun vs. Computer Science (2016)

#21

Post by dmytroi »

im3w1l wrote: post #16
dmytroi wrote: post #11

Earlier quoted context omitted.

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.

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++ templates were used mostly for math libraries (2d/3d/4d vectors, matrices, etc) and containers (hashmap, lists, etc). If we look closely on math libraries we can make a compromise "just float is enough", and if we make such compromise then everything is simple - one don't need templates for math lib anymore, I'm currently using "gb_math.h" [1] and it works pretty good. Containers on the other hand are more challenging, the key here is to understand "can I make this work with linear (maybe static) array?" - and in most cases yes, then you don't need any containers because just arrays will do. If algorithm specific do require a hashmap or list, well, gonna use what we have: macro! It looks weird, and it is weird, but something like khash.h [2] works fine in production.

In reality what it means for me is that I need to spend time making decisions about containers, which is good for game development, as what makes games fun doesn't have any connection to templates. But it also bad for casual non-game related code. I find it much faster to just "hey load this json, do some processing, and save json back" do that in Python than trying to do in C just for sake of C. Ideally namespaces/templates and operator overloading in C would solve all this struggles, but then where C ends and C++ starts?

- [1] https://github.com/gingerBill/gb/blob/master/gb_math.h - [2] https://github.com/attractivechaos/klib/blob/master/khash.h

Re: Fun vs. Computer Science (2016)

#23

Post by Karrot_Kream »

I 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 typing. While rapid iteration languages and environments are good for initial development, they can be awful for projects requiring maintenance.

About a decade ago, I built a small web app using Common Lisp (SBCL) and a lot of the development I did was done through adding new features and debugging in the REPL. While I saved the VM, reading the code months later to add a feature was terrible because the app was hacked together. I wonder if there's a way to fix this. Typed Racket looks like a promising move in that direction.

FWIW, ghci already interprets Haskell quite quickly for iterative development.

Re: Fun vs. Computer Science (2016)

#24

Post by mpweiher »

Karrot_Kream wrote: post #23

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

Good points.

> derive algorithms mathematically

Of course, most of what computers do is not algorithms (or even "computing").

> can be awful for projects requiring maintenance

Or wonderful, see Smalltalk. Not that it is perfect and can't be improved, but it sure has been successfully maintained over a long period of time.

Re: Fun vs. Computer Science (2016)

#25

Post by Grustaf »

I'm considering writing a post about "Fun vs physics". In it I will explore rhetorical questions like

"does higher build quality make formula 1 cars faster"

and

"do better materials in a car make it more fun to drive"

Re: Fun vs. Computer Science (2016)

#26

Post by brailsafe »

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

Correct me if I'm wrong, but hot-swap requires a very particular set up and would be tricky to implement after a legacy java based stack has been established no? Mind elaborating on that a bit? I worked in frontend on such a system and looked far and wide for something that would let me maintain my sanity such as a turnaround time of less than 10 minutes.

Re: Fun vs. Computer Science (2016)

#27

Post by abhirag »

Karrot_Kream wrote: post #23

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

"About a decade ago, I built a small web app using Common Lisp (SNACK) and a lot of the development I did was done through adding new features and debugging in the REPL. While I saved the VM, reading the code months later to add a feature was terrible because the app was hacked together. I wonder of there's a way to fix this." -- I think you might like clojure.spec, I feel that it is a step in the right direction towards keeping the flexibility and interactivity of lisp while making the code more maintainable. You can find more about it here -- [https://clojure.org/about/spec].

I also wrote a small article on it, not very detailed but maybe it can help you get a rough idea of the power of clojure.spec when combined with generative testing -- [http://abhirag.in/articles/spec_oracle.html]

Re: Fun vs. Computer Science (2016)

#28

Post by Grustaf »

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

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

Re: Fun vs. Computer Science (2016)

#29

Post by ece »

kabdib wrote: 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 you can cut down on iteration times by mostly forcing the IDE to do incremental compiles. You can work in real-time on code that might take tens of minutes for a full build.

TDD is fun.

Re: Fun vs. Computer Science (2016)

#30

Post by DonbunEf7 »

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…

Well, actually, let's explore the metaphor. Here's how I compose music.

First, I use a highly-flexible prototyping instrument to quickly iterate on melodic ideas. Normally this is either humming or whistling. "Our first instrument," as an instructor used to call it. I do this until the melody is catchy enough to start sticking in my mind. Then I'll look at alternate parts, like countermelodies, B/C sections, harmonies, or basslines. Each part gets repeated until it gets stuck in my head.

Then, I repeatedly hum/whistle each part like a disturbed rambler until I get home or to some other place where I can scribble the parts down onto paper. I used to be faster just typing out the Lilypond, but I'm out of practice with that whereas all musicians generally never stop having a short shitty hard-to-read staff-based shorthand.

Now, finally, I actually start playing the different parts on actual instruments, figuring out stuff like fingering for guitar or piano, rhythm and phrasing, filling out transition chords, etc. During this process, I play less and less of the song, drilling down to tiny fragments and setting up tiny local contexts for testing ornaments, phrasings, hits, etc.

If I'm gonna try to make the metaphor rigorous, there would be only one language, because the musical process happens entirely in one language. This language is small enough to write on a single piece of paper, fully contains all of its abstractions, has focused notation for specific instruments, and permits debugging any part of a program by cutting any contiguous subprogram out and turning that fragment into its own live environment.

I'd write a program first on a prototyping platform which is so lightweight that nearly any prototype program will run, and I'd use that to write out the entire first draft of my program. Then, I'd incrementally move pieces of my program transparently onto a more rigorously-precise framework which is more restrictive about types but makes it easier to compose modules and let them stay composed.

There is a point in time when composition is more about managing multiple parts at once and you won't actually want to listen to more than about 15s of your song at once, and you'll want your runtime to support your quest towards stability as a basis for tweaking the fine details of your song.

Post reply on HN