Live data from Hacker News

Fun vs. Computer Science (2016)

prog21.dadgum.com

131–140 of 184 posts

Re: Fun vs. Computer Science (2016)

#131
post #5
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…

With a good IDE with an integrated debugger Python and its ilk, and even Java, are like clay. PyCharm, IntelliJ, and their siblings.

More like cement. I don't mean to be dismissive, but REPLs aren't created equal. I've used good IDEs with Python and Java and C#. The C# debugger is probably the best, but its really not the same thing. Python could probably embrace it more so, and if you've used Jupyter, you got a pretty good taste of what it means to mold a running program, now imagine doing that for all programs, not just data science reports.

Re: Fun vs. Computer Science (2016)

#132
post #107
post #91

Earlier quoted context omitted.

Look into success typing

Thank you for the recommendation. I think I found the paper that introduced the idea: http://www.it.uu.se/research/group/hipe/papers/succ_types.pd... 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 h…

I agree. Yet I want as much inference as possible as you described upthread

Re: Fun vs. Computer Science (2016)

#133

Earlier quoted context omitted.

So is python, which is a much nicer language.

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…

Python can reload modules while running. This is standard practice. And anyway, bouncing a Python process is instantaneous.

Re: Fun vs. Computer Science (2016)

#134
post #122

Earlier quoted context omitted.

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…

Um, we have those languages NOW. We've had them for decades. You just need to use them: https://www.haskell.org/

If Haskell was a solved problem, Haskell 98 and Haskell Prime wouldn't exist.

Re: Fun vs. Computer Science (2016)

#135

Earlier quoted context omitted.

Nowadays I feel that experience with some type system at least as powerful as Haskell's is required to criticize static typing... Well, of course, you can criticize it without such experience, but that only serves to look foolish when you complain about stuff that is solved for a decade. Are you really complaining about lack of generics?

Come back to me when the most used programming languages have a type system like Haskell's. Then we can talk about the benefits of static typing over dynamic typing. Until then, static typing is mostly "expected a HashMap , got a HashMap " or other pedantic stuff like that which is only really meaningful to the compiler.

You are confusing "static typing" with "algebraic typing", which is related but different.

Re: Fun vs. Computer Science (2016)

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

Not really, I often don't need them. They're mostly for being able to reset the full app state back to how it is at startup. You can also just restart the REPL, though some people find waiting 5 second for that too annoying.

I wish the restart times were much faster, but its not as big a problem as most people make it sound like.

Often time, you can just learn to mold your program in smarter ways, so that you don't get yourself in weird inconsistent states, or you learn how to fix your state instead of starting over. Or you use mount, components. Integrant, etc. They're really low overhead, mount is trivial to add, its like 4 more characters per global variable.

Having said that, Clojure isn't the best thing ever, just the most interactive language I know of currently that is mature enough and has a large enough ecosystem I can use it for commercial software. Do you have other recommendations for a language that meets these criterias?

Re: Fun vs. Computer Science (2016)

#138
post #109

Earlier quoted context omitted.

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

> It's pathetic that we're still discussing these in 2017.

Evidently most language creators find it difficult to integrate both interactive programming and static typing, which suggests to me that the problem is not easy. Or maybe there just isn't enough overlap between the groups who value one or the other.

> just stuff all your top-level definitions into mutable cells

That seems like it could be part of a potential solution, but it would require rewriting the program so that everything is implicitly wrapped in the IO monad. And it still doesn't handle the case were you want to add to an existing data type.

Re: Fun vs. Computer Science (2016)

#139
post #122

Earlier quoted context omitted.

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…

Um, we have those languages NOW. We've had them for decades. You just need to use them: https://www.haskell.org/

I've used Haskell, have I overlooked parts of it? How does it solve my problem?

Also lazyness I'm not a super fan of. And I/O is kind of a pain, not sure its worth the overhead just to achieve purity.

P.S.: I encourage people to use Haskell though. Its a great language, a step forward in a lot of ways, I'd be happy using it for work, just not as happy as I'd want to be, because of the problem I explained above.

Re: Fun vs. Computer Science (2016)

#140
post #138

Earlier quoted context omitted.

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

> It's pathetic that we're still discussing these in 2017. Evidently most language creators find it difficult to integrate both interactive programming and static typing, which suggests to me that the problem is not easy. Or maybe there just isn't enough overlap between the groups who value one or the other. > just stuff all your top-level definitions into mutable cells That seems like it could be part of a potential…

> Evidently most language creators find it difficult to integrate both interactive programming and static typing.

Interactivity is one thing. Randomly redefining things is a-whole-nother thing. ML and Haskell are interactive. They just don't stuff absolutely everything in mutable cells like most dynamic languages do.

> That seems like it could be part of a potential solution, but it would require rewriting the program so that everything is implicitly wrapped in the IO monad.

You can't have it both ways: either you have effects and accept that you have effects, or don't have effects and accept that you don't have effects. (IOW, lying is bad.)

Post reply on HN