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

91–100 of 184 posts

Re: Fun vs. Computer Science (2016)

#91

Post by branja »

yorwba wrote: post #72
catnaroek wrote: post #65

Earlier quoted context omitted.

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

Look into success typing

Re: Fun vs. Computer Science (2016)

#92

Post by thesmallestcat »

jaipilot747 wrote: post #89
thesmallestcat wrote: post #81

Earlier quoted context omitted.

You don't know what you're talking about. Python process needs to be bounced, or has to watch files and bounce itself on change. The PHP runtime is designed to read the file on each request. You have to go out of your way to require restarts (it is an optimization). PHP has the only mainstream runtime AFAIK that is designed this way (+ the model is stateless, so each refresh really is one). I'm not a PHP fan but it b…

This message would have been just as effective without the opening accusation.

Sorry, you're right, I was annoyed by the "hurr durr Python" tone.

Re: Fun vs. Computer Science (2016)

#93

Post by catnaroek »

yorwba wrote: post #72
catnaroek wrote: post #65

Earlier quoted context omitted.

> 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 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 partially automate the process.)

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

My point is precisely that type systems aren't normally used to enforce data structure invariants directly. Instead, data abstraction (i.e., the inability to inspect the representation of abstract data types from client code) is used to confine the potential to break data structure invariants to a small fragment of a big program (namely, where the abstract data type is implemented). This is in furious contradiction with the idea of inspecting and modifying anything anytime from anywhere.

Re: Fun vs. Computer Science (2016)

#94

Post by CJefferson »

kachnuv_ocasek wrote: post #45
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...

That discussion is over a year and a half old.

True, but in my (very limited) Haskell experience, it's got worse since then, not better.

Re: Fun vs. Computer Science (2016)

#95

Post by coldtea »

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…

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++?

Re: Fun vs. Computer Science (2016)

#96

Post by mpweiher »

mbrock wrote: post #34
mpweiher wrote: post #24

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?

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.

Re: Fun vs. Computer Science (2016)

#97

Post by coldtea »

mbrock wrote: post #66
falcolas wrote: post #57

Earlier quoted context omitted.

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…

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

>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

So maybe liking developing in them depends on having that personality trait? (or typeclass if you prefer, pun intended).

Re: Fun vs. Computer Science (2016)

#99

Post by mbrock »

coldtea wrote: post #97
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...

> 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 So maybe liking developing in them depends on having that personality trait? (or typeclass if you prefer, pun intended).

Maybe, I don't know. The psychology of programming language preference seems like a pretty interesting topic. Enjoying programming at all seems like it might depend on some quirks; I don't know if there's a significant difference to make you inherently prefer fixing type errors over fixing unit tests or whatever.

Re: Fun vs. Computer Science (2016)

#100

Post by Scarbutt »

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…

To be fair, in Clojure you have to reach for horrible external hacks like Component and Mount to have a "real" interactive development.
Post reply on HN