The author has a point that I generally agree with, but note that PHP, JavaScript and Basic all went through a phase of revision that made them more 'CS conformal', removing some notable corner cases in how they worked. (On the other hand, C++ has also had some corner cases removed over the years...)
Fun vs. Computer Science (2016)
111–120 of 184 posts
Re: Fun vs. Computer Science (2016)
#112Re: Fun vs. Computer Science (2016)
#113Earlier quoted context omitted.
While I agree with the first part (immediate feedback is essential), I'm not sure about the connection with LISP in the end. Doesn't LISP offer the same "fast feedback" cycle that e.g. PHP or whatever does? And even faster than C++?
It's kind of my point: LISP does (mostly) provide instant feedback, but it's not used much in the real world (every big LISP success I've heard of wound up either being translated into a shlub language, or resulted in the teams using it having a really hard time hiring people and scaling).
Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else.
It's hard to break this habit of familiarity, it's self replicating, because the less familiar people are, the less likely they can have good teachers and teaching material about it, etc.
Re: Fun vs. Computer Science (2016)
#114Earlier quoted context omitted.
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...
Thanks, that makes sense (also to cormacrelf).
Re: Fun vs. Computer Science (2016)
#115Earlier quoted context omitted.
> but there are still type systems that can catch a lot of errors in practice. I have yet to see a type system that can take a putative implementation of a data structure with arbitrarily complicated invariants, and spits out whether the implementation is correct or not. (Note that Coq, Agda, etc. don't quite fit the bill, because they require the programmer to enter the proof himself , even if these tools can partia…
I'm not talking about the kinds of invariants that require an undecidable type system to formalize, but about the most simple things. "Any value passed to this function can be iterated over." "This sequence of checks is exhaustive." "Calling this function with these arguments won't throw an exception." Those tend to be the mistakes I make when programming interactively in Python. Forgetting to put a single value into…
> Those tend to be the mistakes I make when programming interactively in Python.
Those tend to be the mistakes that I take for granted any seasoned programmer can detect and fix almost instantaneously and effortlessly. (Of course, not because programmers are superhuman, but rather because Hindley-Milner is the bare minimum a high-level language should have.) It's pathetic that we're still discussing these in 2017.
> Yes, in some cases those properties can only be verified by proving some invariant equivalent to the Collatz conjecture.
I have yet to see a useful program whose correctness is contingent on the Collatz conjecture being true. But I have seen lots of programs that are much easier to verify by hand than using a type system.
> I'm not too worried if it can't prevent me from invalidating invariants, so long as it can prevent me from making simple mistakes that are obvious in retrospect.
I'm not worried either. I'm just saying that “allow anything to be modified anytime, anywhere” is counterproductive. But if you really want to do it, you can do that in ML and Haskell too: just stuff all your top-level definitions into mutable cells.
Re: Fun vs. Computer Science (2016)
#116I 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…
It's true, but it's more a treatment then addressing the root cause.
Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL."
My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large picture of the code.
Re: Fun vs. Computer Science (2016)
#117Video games are getting massive and they're not slowing down much. We're relying more and more on the engine to do the hard work for us and leaving the creative stuff to the humans. The only way I can see video games moving forward is to have a massive fixed costs of development in reusable, optimized code, and push all the variable costs onto the individual game made by the individual humans making them. The stuff that goes in libraries and into the game engine and even the tools needs to start sticking around longer and to be sane and safe. Basically, it's what almost every engine has already discovered: game scripting and game logic can use its own language optimized for development time and accessibility. We can leave Python to the animators and level designers, but keep your Rust and your Go and your fancy data structures to people who are building the infrastructure.
Re: Fun vs. Computer Science (2016)
#118Earlier 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.
Fortunately, computer science still literally means just that - it's an exploration of the properties of computers. As to humans developing computer based systems, yes, scientific rigor is not mandatory, just as you don't require understanding classical mechanics to build an abode. As to the psychology at play with humans developing and using computer based systems, rigorous psychology is eminently suited to your concerns.
Re: Fun vs. Computer Science (2016)
#119Earlier 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.
I would like you to cite some papers, which claims it makes language X better/worse without any explanation.
Re: Fun vs. Computer Science (2016)
#120I 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.…
Well, yea, hopefully in the future we have languages that allow both. I do feel like research in language design has ignored the interactive and fast feedback loop aspect though, at least from the reasearch I know of.
My biggest gripe with static checks, is that in reality, most of the software most programmers are asked to write don't need to have 100% correctness. As long as 95% of the most likely to occur and the most user impacting bugs are fixed, the rest doesn't matter.
So I'm really interested to see the optional type system research mature more. When I start programming, I rarely know what the functionality should be, I have a vague idea, but I need to experiment. I don't need each experiment to be correct, at that phase it could have tons of bugs, as long as it can give me a sense for the functionality, and allow me to demo it to the business so they get a similar sense. Static checks slow this process down a lot, even though I do have fun making each experiment correct, its really just a waste of time for the product.
But as the desired functionality gets clearer and clearer, then I'd want to start working towards that 95% correctness, and types are quicker to write then tests. I'd rather have types to assert type errors, borrow checks to assert no memory errors, and tests to assert functional errors. Then have to write tests to assert all three, because tests are the slowest to write. But writing 100% type annotations or memory annotations is too much, just like I wouldn't write 100% test coverage in practice. That's because most software needs 95% correctness. Not 100%. So this is the struggle I feel.