101–110 of 184 posts
Earlier quoted context omitted.
Can you expand on what is meant by algorithms and computing, and what you mean that computers mostly do instead?
Computers today mostly (a) communicate and (b) store/retrieve data. Both at the macro level, what they are used for, but also at the micro level. Actual computation tends to be incidental.
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…
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++?
Earlier quoted context omitted.
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
For web development, yes. Once you know pretty much what you want, and have a good idea of how you're going to go about implementing it, it can be fast. If you're new, don't know what you want, and are starting out on a framework, it can be an impassable chasm. If you're just experimenting, it's also a bit too much. Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD t…
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...
I'm using Haskell at work at the moment and while rebuilding everything and rerunning all the tests takes a frustratingly long time, reloading just the module I'm working on and playing with my changes is so fast I don't notice any delay. In practice, this means that 95% of any given task feels great but the final 5% before I'm done can be a real pain because I need to rebuild everything to faithfully reproduce our production environment and that does have a slow iteration time.
Earlier quoted context omitted.
Computers today mostly (a) communicate and (b) store/retrieve data. Both at the macro level, what they are used for, but also at the micro level. Actual computation tends to be incidental.
Yet you can't just tell the computer to communicate or do I/O -- it's all controlled by decisions, and making those decisions is basically what I call computation.
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.
Earlier quoted context omitted.
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 wh…
Look into success typing
If I understand correctly, success typing rejects only programs that will lead to a type error at runtime, but allows all programs that it can't prove incorrect. I think that's an interesting idea and definitely better than no type checks at all, but I'd still like to have a type system that can prove some programs to be type safe, if possible.
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…
To be fair, in Clojure you have to reach for horrible external hacks like Component and Mount to have a "real" interactive development.
[0]: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r...
Earlier quoted context omitted.
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 wh…
> 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…
Those tend to be the mistakes I make when programming interactively in Python. Forgetting to put a single value into a one-element list. Forgetting to check for None. Misspelling a key in a dictionary. Swapping the order of two arguments in a function call.
Yes, in some cases those properties can only be verified by proving some invariant equivalent to the Collatz conjecture. I'd conjecture that most instances could still be solved by an appropriate 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.
Earlier quoted context omitted.
Yet you can't just tell the computer to communicate or do I/O -- it's all controlled by decisions, and making those decisions is basically what I call computation.
Yep...incidental computation. Also: "primarily"/"mostly". Not all/none.