Earlier quoted context omitted.
> The PHP "builds" as fast as I can refresh a browser page JavaScript is just as fast, or faster. That's probably an important reason why it's "eating the world".
So is python, which is a much nicer language.
Fun vs. Computer Science (2016)
81–90 of 184 posts
Re: Fun vs. Computer Science (2016)
#82I think, to some degree, the idea that drives strongly typed, theorem proved languages is a bit different than what most people think of when coding. A large set of people in that community want to derive algorithms mathematically, using a deductive or proof based process, as in math. Iterative development conflicts with a top down form of development, and also conflicts with the safety oriented culture of strong typ…
One thing to remember - the domain under discussion in the article is gaming. There's little maintenance typically involved with games. There's more today than there was yesterday, but it's still not a system expected to be built, maintained, and extended for decades.
Re: Fun vs. Computer Science (2016)
#83I 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.…
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…
Are you really complaining about lack of generics?
Re: Fun vs. Computer Science (2016)
#84I 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...
It does not change the fact that GCH is slow, since you must do full compilations once in a while. But it does let you keep your flow while developing. Besides, GHCi is much faster.
Re: Fun vs. Computer Science (2016)
#85Ill give you one clue or more like a hunch...
If you have a tool that is trying to do everything it isn't going to be equally great at all those things and it will likely be confusing/hard to use.
The generic programming languages tend to be more popular but they do so in the same way TV programs or video games are trying to appeal to an audience as large as possible. (This is how we got all these absurd hacker movies for example)
In the future (lol) we will discover that single purpose languages are just better at the limited scope of things they do.
PHP is perhaps a bad example that I shouldn't even have mentioned here but such a language knows exactly what its goal is in life like PHP knows it is suppose to bake websites.
Maybe you've touched the awesome with your fun. Someone should try build a language entirely around the core mechanics of fun.
In games there is fun in the form of rewards for stuff that just takes a fucking long time to do, there is fun from rewards for stuff that requires skill, there is fun from rewards obtained though luck, there is fun from a storyline progressing, there is fun from unexpected things, fun from buying ingame shit, fun from selling ingame shit, fun from cooperation as well as growing to be able to do those things on your own.
But the real list is probably much longer.
The language should probably have a basic fun object that looks something like: { temporal: 0. skilz: 0, luck: 0, story: 0, randomEv: 0, pay2win: 0, progaming:0. coop: 0, solo: 0, [...etc...] }
Then you have to benchmark the fun people are taking out of a bit of code or graphics using real world data.
And then....
Then you would be able to focus your attention where your effort produces the largest amount of fun as well as see the areas where your game is teh suck. Answer the big questions like what parts are people playing and why? Where do they rage quit?
If they didn't give up on creating content for Diablo 2 I would probably still be playing it.
If they had a language where fun was the central mechanic they would have known that changing all the items and ruining all the heroes had a negative dev time to fun conversion ratio.
It wouldn't have to be limited to games at all. One could quantify the fun on HN using the same language. It would all of a sudden be obvious that the karma system and submission ranking lacks random rewards and events. A thing no one considered up to now but if we know it is fun and the system is lacking it it becomes worth considering it.
Re: Fun vs. Computer Science (2016)
#86Earlier quoted context omitted.
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…
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
Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD too) can be easier to start with and change as you figure out what you want. Even with specs, or a BDD framework like you said, no need to bring in a whole new DSL unless you need it IMHO, others may disagree.
Re: Fun vs. Computer Science (2016)
#87Earlier 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...
It's funny how when someone describes their own experience, you tell them they're wrong. Are you claiming the GP didn't actually experience fast reloads? Initial compiles of some Haskell libraries that essentially do exponential inlining ( cough vector-algorithms cough ) can take a long time. An incremental non-optimized compile of a small change to a project with a good module structure takes a couple seconds. The G…
Nobody is saying anyone is wrong. One person can perceive short compile times that another thinks are long. But, we shouldn't make generalizations based on one datapoint. Maybe you _can_ have fast builds with Haskell, but maybe that isn't the norm.
Re: Fun vs. Computer Science (2016)
#88Earlier 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...
> find the process of fixing type errors quite enjoyable I, myself, would rather be creating new functionality than fixing a litany of type errors. In fact, I'd rather go to a meeting than change several hundred instances of 'duck' to 'waterfowl', 'avian', and 'ugly_duck' (knowing that I'll probably have to go back and change it again later). Different strokes for different folks, I guess.
Re: Fun vs. Computer Science (2016)
#89Earlier 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…