/dpt/ - Daily Programming Thread

What are you working on, Sup Forums?

Old thread:

Other urls found in this thread:

youtube.com/watch?v=0jYdu2u8gAU
pastebin.com/Y9mFtDDA
fluentcpp.com/2017/10/23/results-expressive-cpp17-coding-challenge/
twitter.com/SFWRedditImages

Daily reminder that blublets who can't grok lisp don't deserve to be called programmers.
Daily reminder that programmers who actually grok lisp don't attempt to shit on it, because they know they'd only be smearing themselves.

Daily reminder that Lisp is dead because Lisp is shit.

how do I make haskell do something, anything?

>the blublet immediately exposes its delusional nature by making retarded statements
Thanks for illustrating my point about smearing yourself with shit.

>how do I make haskell do something, anything?
IO monads.

IO, State, Either + C bindings

Translate it to C++ code, and then compile it with g++.

Thoughts on my OC?

Reposting with more whitespace at bottom

What's wrong with hex fp literals?

ugly danish gnome

not in c

>What's wrong with hex fp literals?
More bloat.

>You can't make games in Haske-

youtube.com/watch?v=0jYdu2u8gAU

ll

>you can use X to do Y, therefore you should use X to do Y
>this is how language bigots actually reason

Whom are you quoting? No one said that, you can even make games in PHP or Lisp if you hate yourself enough.

One or too games have been written in x86 assembly as well.

>implying lisp isn't a very comfy language for games
Blub syndrome at its finest.

homostank is poop

lovely stable framerate

Too slow/memory hungry for anything other than scripting, no better for scripting than industry's standards like Lua and Python.
>inb4 naughtydogs
Right, one company out of thousands used a lisp-like language in some old games exclusively for scripting.

>windows
so this is the power of hashcucks

>X is too slow
Nobody cares to discuss your vague subjectivist statements, user. Do you have some concrete evidence of specific things that lisp isn't fast enough for?

good thing my captcha failed I was about to write a snarky response to this post but I decided against it because I didn't want to lower the tone of the discussion

Yes, I do, but it's not like you're not going to deny all of it because feels >>> reals, and proceed in your delusion what a dynamically typed language with GC can be fast enough for actual gaming programming.

Besides, does SBCL even support AVX/AVX2 and autovectorisation?

Nobody wants to play your barely 60 FPS 2D game.

So you don't actually have anything concrete and objective to say? You realize "X is not fast enough" and other noises you can make with your mouth aren't arguments, right? Not fast enough for what, exactly? Is it not fast enough for any game?

See

Games are all about the experience, i.e. it's subjective. Fuck off with your autism.

>benchmark results
>compiler still being unable to generate 5+ yo instructions
>compiler doesn't autovectorise
>not concrete and objective
Keep blubing, my friend, don't let these facts disrupt that world you've built in your head where Lisp is still relevant.

Is functional programming a beautiful lie?

newbie here looking for help

so I'm doing a cellular automata right, and I wanna do a line graph of the population over time. It'll have a fixed height and weight, say 1500x500 for example. I want to do it so the whole graph is visible after every update; say you can see the progression from generation 0 to current generation at all times, instead of the graph just covering the last 1500 generations. How should I go about this? When there's less generations that there's pixels available it's fairly easy to plot, but I don't know how I should go about plotting 50,000 generations with 1500 pixels.

>Games are all about the experience, i.e. it's subjective
There's nothing subjective about whether or not a particular game runs at a high and stable frame rate or not. I've made fairly complex games before in CL, and they ran at a stable 100+ FPS on what were back then considered modern machines (and now considered fairly old), so please explain what games lisp isn't fast enough for in your plentiful experience.

Link to these games + source? Otherwise you're full of shit.

>makes purely subjective "X is not fast enough" statements without specifying any context or providing any evidence
>proceeds to post irrelevant charts to show that X is not as fast as Y, still not providing evidence that X is not fast enough for any specific game development use case
>screeches autistically that he's being objective
Also, see

>Link to these games + source?
Nope.

>Otherwise you're full of shit.
You can say that all you want, but the burden of proof is actually on you. I'm just telling you that my experience contradicts your (so far unsubstantiated) statements.

> Is functional programming a beautiful lie?
The only lie out there it that FP is possible without static typing. No, having functions as first-class objects doesn't make your language functional, otherwise, we would have to call Python and PHP "functional".

>i've made fairly complex games in cl before
>hurr durr the burden of proof is on you

Lisp works well in a functional style

>I've made a Tetris in lisp once
>That means Lisp is fast enough for game programming
I thought we're talking about actual game programming.

Bullshit. The original lambda calculus is untyped, and it's more powerful than the typed version.
Try writing a simple Id function in a cute language like Haskell. What if I want it for multiple types?
That's right. You can't.

id :: a -> a
id x = x

>haskell
>1GB/s

Not typed anymore.

...

The unique things about Lisp - homoiconicity and macros - have nothing to do with FP. From FP POV, Lisp is no different from Python - both support functions as first-class objects. Yet we don't consider Python a "functional" PL, why should we do so with Lisp?

>the absolute state of haskellfags

Daily reminder that Lisp is dead because programming is for brainlets.

as long as the game will run on most people's computers without lagging often, people do not give a single shit. there is a lot of room for being terribly made while still meeting that condition.

Are there people who unironically believe FP has anything to do with static typing?

In case you're not just pretending to be retarded, the full type of the identity function in Haskell is forall a. a -> a. This means if x :: b then f x :: b. This is called parameteric polymorphism and is a feature of Haskell's static Hindley-Milner type system.

The only two languages you will ever need are C++ and Haskell. Hence why I'm writing my latest game (the two games I've previously published on Steam have sold over 300 copies in total) in C++ with interpreted Haskell as an embedded scripting language.

Evidently.

> The original lambda calculus is untyped
Right, but the last 70 years of theoretical development of LC was focused on types. It's like saying the original math was about arithmetics, so we shouldn't use calculus.

Either FP is about typing, or PHP is a functional programming language.

That doesn't mean FP isn't possible without static typing. You can very well find the GCD of two numbers without using calculus, only basic arithmetic.

pastebin.com/Y9mFtDDA
+100 lines worth of "expressive" "state-of-the-art" C++ lmfao

import std.stdio, std.algorithm, std.range;

void main(string[] args)
{
auto source = File(args[1], "r");
auto output = File(args[4], "w");
const auto change_at = source.readln().split(',').countUntil(args[2]);
writeln(change_at);
writeln(args[3]);
foreach (line; source.byLine())
{
foreach (index, word; line.split(','))
{
writef("%s ", index == change_at ? args[3] : word);

}
write('\n');
}
}

fluentcpp.com/2017/10/23/results-expressive-cpp17-coding-challenge/

PHP is a functional programming language, unironically. And I think PHP sucks.

>unironically using iostreams in 2017

Enjoy your \0 terminated char*, grandpa

>make dumb claims
>can't back the up
>think i have to prove them wrong by sharing code from my personal projects
Burden of proof is entirely on you. I'm just telling you that my experience contradicts your (so far unsubstantiated) statements.

>fast enough
See the thing about games and other boundless processes (offline rendering, AI etc.) is that the more power you have the better you end up. Be it making pretty graphics or massive simulations games will be demanding until we breach the limit of human perception and human reasoning.
Other fields are swimming in resources. That's why high end games are largely made in C++. Despite it being a terrible language.

You can of course write something that qualifies as a game in any language but you'll be kicking yourself for running out of resources when you have a cool feature to add that you can't add because you're resource constrained.

Enjoy your overengineered, bloated library

>pic
It's probably just a joke but I know someone will think that coroutines is a universal solution to multithreading problems.
It's not.
Thanks for reading.

>muh edge cases

>splist at ,
>writes without ,
Can't even write 10 lines without a bug.

don't like it? don't use it :)

Either you're completely retarded and don't understand that you're the one who has to prove his (((experience))) or you're trolling.

>the more power you have the better you end up
>you'll be kicking yourself for running out of resources when you have a cool feature to add that you can't add because you're resource constrained.
By your retarded "logic", we should all be writing every single game in hand-tuned assembly, just to make sure we don't run out of resources, because clearly every single game requires Crytek 6-tier graphics and physical simulations. Now let me turn around your statement back against you: the more power you have, the better you end up. That's why you should choose programming languages with great expressive power. That way you don't end up kicking yourself when you have a cool feature to add that you can't implement because it's a painful clusterfuck to implement in your crappy blub language.

>splist at ,
>splist
Can't even write 3 lines without spelling mistakes.

Unpopular opinion: unless working on very large projects, dynamic typing is better. It's also great for writing interpreters.

>you're the one who has to prove his (((experience)))
I don't have to prove anything at all because the burden of proof has been entirely on you from the very beginning, and your position is inherently untenable. But just to complement your impotent rage a little further, I'm repeating that my experience completely contradicts your unsubstantiated claims, so I'm confident that no substantiation for them is ever going to come. Stay mad, kid.

Type inference and algebraic data types cover most of the cases in practice I've seen where people claim dynamic typing is better.

>very large projects
It's actually anything more than 100 lines of code.

many decimal values are not exactly representable by a given floating point implementation (IEEE-754 can't store a value representing exactly 0.1, for example), and this can introduce error. hex float literals allow you do describe a float which is guaranteed to be exactly representable by the implementation. achieving this effect using type punning is less than ideal because (1) it's not necessarily portable across floating point implementations and (2) most of the ways people do so in C++ are actually undefined behavior regardless

I haven't programmed in a dynamically typed language where dynamic typing didn't cause me issues by being cryptic in some way or another. Maybe I only take on big projects.

Maybe people who use dynamically typed languages eventually learn the intricate environment and see past the issues by adapting themselves to the language.

To me it's difficult to understand why someone would want dynamic typing at all. It only saves you time in variable declaration. Mostly not even there.

Don't b rude. I plan on moving to C/C# after I get comfortable with java.

>Lisp looks like a bad choice for game programming, and here's why: [..]
>Bullshit, I used to make a game, therefore it's perfectly fine for real game programming
>Interesting, can you show us the game?
>Lol no.
>Then we have to disregard your claims.
>The burden of proof is on you, you have to disprove my subjective experience without me providing anything, your position is inherently untenable, retarded "logic", impotent rage, stay mad, crappy blub language
Truly lispers are as impossible to have a constructive discussion with as religious fanatics.

>To me it's difficult to understand why someone would want dynamic typing at all. It only saves you time in variable declaration. Mostly not even there.
Dynamic typing and binding helps you create very flexible structures that can evolve without constant tedious refactoring. Very beneficial for rapidly prototyping and scrapping features. This is especially true for games, in my experience.

>real language
>rebranded Java
You'll never make it

>lisp can't be used to make any games because it's slow!
>"i've made some games in lisp and it wasn't too slow. care to explain what lisp is too slow for and substantiate your claims?"
>hurrr now YOU have to prove that lisp is not too slow for everything!
Literally subhuman, as expected from anyone who would make "X is too slow" statements in the first place.

>we should write everything in asm
Only if you feel proficient and have those needs.
No. What I'm saying is that if you have ambitions having some decent footing is a good idea.
>expressiveness helps development
In the few games I've written I've found myself being very quickly limited by resources, mistakes/bugs or going along at a very rapid pace. Being expressiveness bounded seems odd to me. Almost any problem I can think of that I've had that's relatively onerous to do is mainly in data definition. It's when you find that gap between it being worth to generate the data vs just inputting it. I suppose greater typical programming expressiveness lessens that gap. But it's such a minor issue.
Of course expressiveness is one of those words that's task defined. Of course if you had more general expressiveness improvements that's always a boon. You rarely actually do though.

There's the guy from a couple months ago with his lisp minecraft clone. Its not a crysis but its also no Tetris.

Short . Yes

value types alone are enough to make C# measurably better than Java, let alone all the other shit

Both Oracle Java and Microsoft Java are shit, at least the Oracle version is more portable and gives you more jobs.

I guess I just don't have problems where I constantly change input and output types.
But even so dynamic languages give you a hard time when you change types usually. It's rare to be able to go from an int/float/string/primitive to a higher level structure without issue.
I find static typing especially helpful when that happens as it highlights everywhere you've done a wrong with regards to the new type.
Where you change between the primitives it's mainly just an issue of changing it once. Even in pitiful excuses of a language like C++ if you use auto everywhere it's not a major hassle to change a type somewhere.
But for very small problems I see less problems. There's usually not that many places in your code where you expect specific types. And you could probably debug most of your program quickly.

Value types are inconsistent with the semantics of the rest of the language
var a = new Foo();
a.bar = 10;
var b = a;
a.bar = 20;
b.bar //what is this value?
Oh wait, properties already make it impossible to make any such assumptions anyway.

More features does not imply better language

>What I'm saying is that if you have ambitions having some decent footing is a good idea.
Mhmm, and that's why I don't use trash like C++. You need some decent footing if you want to implement complex game mechanics and features.

>In the few games I've written I've found myself being very quickly limited by resources
Care to elaborate on what you were doing?

>mistakes/bugs
Many of those come from incidental complexity, which results from a lack of appropriate abstractions, which results from lack of expressive power.

>Almost any problem I can think of that I've had that's relatively onerous to do is mainly in data definition.
What do you mean by "data definition"?

>Modern expressive C++17 with all the bells and whistles on
>STILL can't split a fucking string
>Still no UFCS
It's outright embarrassing.

Again, you can use PHP for it to some extend, the point here it that using Lisp for a task where performance and responsiveness are critical is a premature pessimization.

>It's rare to be able to go from an int/float/string/primitive to a higher level structure without issue
You ever use map Nigga?

G O A L P O S T S

user if no response will ever satisfy you, then you don't really have an opinion, just a butthurt towards lisp.

>But even so dynamic languages give you a hard time when you change types usually
The point is in creating structures that can accommodate changes in type, so that you only have to fix things in specific locations when types change, and not have to modify everything on the path to those specific locations that actually care about the type of a certain value. This can be accomplished to some extent with expressive type systems, but at the cost of either very complex type definitions, or very permissive (and mostly useless) type definitions.

I didn't mean those 4 in a higher level datastructure.
I meant something that generally doesn't share primitive operations with floats/ints...
The actual data transformation you have to do usually needs to be redefined when you change types. Usually because you don't mean to do the same thing with a string and a float for instance.

>a task where performance and responsiveness are critical
This is a meaningless statement. "Performance and responsiveness" are critical for literally any task, so you should use hand-tuned assembly for everything; otherwise it's "premature pessimization".

>This can be accomplished to some extent with expressive type systems, but at the cost of either very complex type definitions, or very permissive (and mostly useless) type definitions.
Type inference completely invalidates this argument.

Dude look up map/filter/fold. Its gonna blow your seppleslet mind.

The idea is you pass the actual transformations in as parameters.