231–238 of 238 posts
Earlier quoted context omitted.
Yes, that's a good point. Some people might not actually need to cultivate a deep understanding of CS -- they just need a tool to get the job done. Not everyone who uses a hammer needs to take carpentry lessons. In that sense, Python can be a very appropriate choice.
> Some people might not actually need to cultivate a deep understanding of CS Most people :)
Earlier quoted context omitted.
If you get excited by showing your friend some silly webpage, but aren't absolutely thrilled by function composition in haskell then you're a coder, not a programmer. You're in the wrong class. The point of programming classes should not be to hide what programming is and show this silly mockery of it which javascript is. It shouldn't veil true programming issues, like correctly reasoning about the structure of your…
slow clap It's rants like these that really harm the perception of the functional programming community. It just portrays you as the archetypal 'misunderstood genius' trying to show everyone in the world how wrong they are and how only the 'true programmers' do what you think is right. Yet none of this is backed up by evidence that the benefits of functional programming lead to better software.
Amen. I've been hearing exactly these kinds of grandiose claims from FP advocates going back as far as 1998. The funny thing is, the same people almost never seem to getting around to actually writing any code of any substance. As far as I'm concerned there are some good ideas coming from the FP community but the more extreme implementations of FP like Haskell have yet to prove their worth in production environments.
Earlier quoted context omitted.
slow clap It's rants like these that really harm the perception of the functional programming community. It just portrays you as the archetypal 'misunderstood genius' trying to show everyone in the world how wrong they are and how only the 'true programmers' do what you think is right. Yet none of this is backed up by evidence that the benefits of functional programming lead to better software.
Yet none of this is backed up by evidence that the benefits of functional programming lead to better software. Amen. I've been hearing exactly these kinds of grandiose claims from FP advocates going back as far as 1998. The funny thing is, the same people almost never seem to getting around to actually writing any code of any substance. As far as I'm concerned there are some good ideas coming from the FP community bu…
Huh?
What is your definition of proving worth in a production environment?
Did you hear recently about bond? It's written in haskell by Microsoft and used in Xbox Live as well as other infrastructure.
There's also facebooks Haxl...
Remember Bump file/etc transfers in Samsung Galaxy commercials? That was written in haskell too.
Earlier quoted context omitted.
A well-designed type-inferred statically-typed language either cannot support the following (which is valid Python), or can only do so with tradeoffs that either stretch the definition of "statically-typed", stretch the definition of "well-designed", or would make the language even more intimidating than monads make Haskell: def fizzbuzz(i): if i % 3 == 0: return "fizz" else if i % 5 == 0: return "buzz" else: return…
I'm not sure what your complaint is. import Control.Monad (forM_) fizzbuzz i | i `mod` 3 == 0 = Left "fizz" | i `mod` 5 == 0 = Left "buzz" | otherwise = Right i main = forM_ [1..100] (\i -> either putStrLn print (fizzbuzz i))
The slightly cleaner thing here would be to take advantage of both strings and integers implementing Show. I'm thinking a bit about whether that would actually work well enough in a teaching language; possibly. (Although if I'm remembering my Haskell well enough, you need to enable existentially quantified types to make this work, which, again not really day-3 material. Probably works fine in like Rust, though.)
Earlier quoted context omitted.
> for the author's usage case (kids wanting to learn to write games that are super easily portable) This is an artificial use case. Kids wanting to learn to write games should be concerned with whatever works on the hardware they have available. Portability is premature optimization at this point.
> Portability is premature optimization at this point. It really isn't. If I am a new developer, you're raining on my parade by telling me that I or my friends will have to jump through a bunch of hoops to run my game. In the context of learning to program as a younger person, this is a pretty big deal. This is anything but an artificial usage case, and is what the author is specifically looking at (education).
Mobile means stuff looks easier than what really is. If you cannot be bothered to jump through hoops, this is not a career for you. What I recall of my novice days is literally one hoop after the other. It is just that some people enjoy jumping (this particular type of) hoops.
And regarding the social aspect, think of the days of microcomputers before the PC. I am too young to have experienced first hand, but I recall my uncle having a Commodore 64 and letting me use it. What I recall is that he had 2 different circles of friends: the C64 guys he traded knowledge and warez with, and his actual friends who really need to come over home to be shown the new feat (if they were interested at all).
Earlier quoted context omitted.
In case anyone hasn't heard of it, Asm.JS is basically trying to turn JavaScript into a similar standard. Combine that with sourcemaps in browser debugger tools and we're really close. I've been using clojurescript recently, and I can even connect a REPL to the browser and make on-the-fly changes just like we've always been able to do with JavaScript.
What I really wish someone would build is this: Create a platform-independent machine language which is designed to be translated into arbitrary other machine languages. Then put the equivalent of FX!32[1] in the browser to translate it to whatever architecture the client is running on. And have a compiler that will compile to both that and to asm.js, with asm.js being used (with consequent lower performance) for leg…
Well, minus the asm.js, which I kind of wish I'd thought of at the time.