Live data from Hacker News

Fun vs. Computer Science (2016)

prog21.dadgum.com

31–40 of 184 posts

Re: Fun vs. Computer Science (2016)

#31
post #21
post #16

Earlier quoted context omitted.

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…

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.

Re: Fun vs. Computer Science (2016)

#32
Computer science and software development are different disciplines, and software developers do value iteration time a lot. Tooling you use and algorithms/programming language principles at play should be viewed independently.

Re: Fun vs. Computer Science (2016)

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

The past is (currently) immutable, and the english idiom to handle this case is "we'll just pretend that didn't happen".

Re: Fun vs. Computer Science (2016)

#34

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.

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

Re: Fun vs. Computer Science (2016)

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

Well then, so much for it being Computer Science...

Re: Fun vs. Computer Science (2016)

#36

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

Re: Fun vs. Computer Science (2016)

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

Hmm, looks interesting, but it's quite unfortunate that making the compilation process be useful at runtime-error-removal is merely optional ("strong mode"). So one wonders how many shops write enough "prototype" code in "weak mode" that they decide to leave it in its Python-like mess instead of rewriting for "strong mode"...

Re: Fun vs. Computer Science (2016)

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

Re: Fun vs. Computer Science (2016)

#40
post #34

Earlier quoted context omitted.

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.

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).
Post reply on HN