Fun vs. Computer Science (2016) • Hacker News Board

Re: Fun vs. Computer Science (2016)

#71

Post by marksellers » Sat, Aug 26, 2017, 2:53 PM UTC

falcolas wrote: post #59

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…

One thing to remember - the domain under discussion in the article is gaming. There's little maintenance typically involved with games. There's more today than there was yesterday, but it's still not a system expected to be built, maintained, and extended for decades.

The engines, though, absolutely

Re: Fun vs. Computer Science (2016)

#72

Post by yorwba » Sat, Aug 26, 2017, 2:54 PM UTC

catnaroek wrote: post #65

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

I'm aware that a fully general invariant checker is impossible, but there are still type systems that can catch a lot of errors in practice. If dynamic modifications have to be taken into account, that makes the problem more difficult, but not necessarily impossible. Even though there are changes that can't be checked at all, those can't be too common, or humans wouldn't be able to handle them either.

I'm not sure why you think that the checking will be painful, it almost sounds like you think that it would be done by the programmer. The whole point of type systems is that they can be checked automatically, so the programmer is prevented from doing something stupid.

Dynamic languages already allow all kinds of modifications that might or might not break invariants or introduce subtle incompatibilities; a type system would only make it safer.

It is also not just a matter of "stopping the program and fixing it". Suppose you are writing a game, and during playtesting you encounter a bug, where something is stuck in an endless respawn loop. In a dynamic language, you could look at the misbehaving code, develop a fix, and immediately observe its effects. This allows you to quickly iterate until you have found a solution that works. Compared to a "stop, fix, retry"-cycle, it's simply going to be faster, even assuming you can reproduce the bug reliably (maybe using some kind of input replay).

Re: Fun vs. Computer Science (2016)

#73

Post by mbrock » Sat, Aug 26, 2017, 3:05 PM UTC

falcolas wrote: post #69

mbrock wrote: post #66

Earlier quoted context omitted.

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.

Well... but usually those are actual errors that you would need to fix anyway.

Re: Fun vs. Computer Science (2016)

#74

Post by jstimpfle » Sat, Aug 26, 2017, 3:13 PM UTC

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…

> Yes, I'm more likely to have incorrect code, and it's probably going to show up while the code is running, and not before. Many times, that's a tradeoff I'm willing to accept.

I find the runtime errors I get from dynamically typed languages typically much clearer (and easier to debug) than many compile-time errors from C++ or Haskell.

I do like C's static type systems because it's needed for efficiency at runtime. (Re-) Compiling C can be close to dynamic execution for not-too-large applications. Often also C++ is needed for easy to use containers, but as some else said here it's really a tradeoff because compiles are much slower (I don't know why that is, but part may be because containers are re-compiled for every compilation unit that uses them).

And the overwhelming majority of bugs really appear on the first run of the dynamically typed code. The bugs that remain would have very often been also bugs with statically typed languages, since these are so ridiculously bad at expressing the simple invariants... They get unusable much faster than they get good at helping with bug-discovery.

Re: Fun vs. Computer Science (2016)

#75

Post by jstimpfle » Sat, Aug 26, 2017, 3:23 PM UTC

chowells wrote: post #43

CJefferson wrote: post #36

Earlier quoted context omitted.

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

It's funny how when someone describes their own experience, you tell them they're wrong. Are you claiming the GP didn't actually experience fast reloads? Initial compiles of some Haskell libraries that essentially do exponential inlining ( cough vector-algorithms cough ) can take a long time. An incremental non-optimized compile of a small change to a project with a good module structure takes a couple seconds. The G…

Well, here's another data point. I made a single file prototype to implement a Tetris game just for fun. I think it was with the Haskell SDL bindings or so, and I went with the most straightforward way about the implementation, and do have a reasonable level of experience with Haskell.

I gave up when the code reached about 400 lines. The compilation times were at 10-15 seconds already, and the error messsages were really ugly.

In short, compilation times depend on how you use complex type system extensions, or even only how much the libraries that you use make use of the type system. (And if you don't use the type system much - it becomes such a bad developping experience in most application domains, or you code performs very badly, etc.).

It was so much simpler to do it in C. <1 sec compiles, incredibly performant with straightforward non-optimized code.

Re: Fun vs. Computer Science (2016)

#76

Post by ece » Sat, Aug 26, 2017, 3:27 PM UTC

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.

A good IDE will go a long way here. Any of the IntelliJ IDEs are interactive in almost any aspect of technical coding. Setting up and running a test is a left click, if you've written the function and annotated it in Scala. I've been trying to use Atom for some embedded coding, and some of the plugins for it are pretty good, but not completely free. MS VS is up there too, but I haven't used it in a long time.

Off course, writing testable code using OO almost requires dependency injection IMO. With FP, it's almost trivial.

Re: Fun vs. Computer Science (2016)

#77

Post by scaasic » Sat, Aug 26, 2017, 3:29 PM UTC

caseymarquis wrote: post #67

falcolas wrote: post #54

Earlier quoted context omitted.

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.

On the backend side, tools like nodemon provide a very similar solution. Then just setup your webpack server to proxy requests to your backend, and you're good to go.

Re: Fun vs. Computer Science (2016)

#78

Post by tcbawo » Sat, Aug 26, 2017, 3:32 PM UTC

ece wrote: post #29

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

have you ever tried BDD (behavior driven development)? one of the interesting aspects of this is being able to develop the test implementation in a different (possible more expressive) language

Re: Fun vs. Computer Science (2016)

#79

Post by fulafel » Sat, Aug 26, 2017, 3:33 PM UTC

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…

Re workflow: A typical one is to sketch something out in the REPL, then paste the code into a suitable function in your module, and live-reload it and test it by calling it from the REPL. You'll also typically define some variables holding your test data in the REPL. Sometimes you skip the sketching out part if you already know what you want to do.

I'm not quite sure what you meant by the dependency question. If you need to reference other namespaces, you can add new (require) imports in the repl or live-reloaded source files. If you need to add completely new third party libraries to the project, that's rare enough that a REPL restart is fine - there's a library to do it dynamically at runtime if you want to though.

Re: Fun vs. Computer Science (2016)

#80

Post by wolco » Sat, Aug 26, 2017, 3:34 PM UTC

bambax wrote: post #38

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…

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

No its not. It's slower.