next »

[kamac]

It was mostly an excuse to get some Haskell practice in anyway. Using Parsec was a hell of a lot more enjoyable than my last parsing experience which involved magical C++ template meta-programming with Boost.Spirit.

Yeah, Boost.Spirit is pretty bad. Hand-written parsers 4 lyfe.

[beakɍ]

On the topic of esolangs, I just finished an implementation of a programming language made up entirely of ASCII art of churros.

Hello world:

Code:

{o}==========} {==={*} {o}} {======{o} {o}=} {={o} {o}} {====={o} {o}=}
{======{o} {o}===} {={o} {o}=} {====={o} {o}==} {======{o} {o}=======} {={o}
{o}==} {====={o} {o}===} {======{o} {o}=========} {={o} {o}===} {====={o}
{o}====} {======{o} {o}==========} {={o} {o}====} {====={o} {*}=} {={o} {===={*}
{{o} {o}==} {======{o} {o}==} {={o} {========{o} {o}====} {======{o} {o}=} {={o}
{========{*} {o}=======} {={o} {========{*} {========{*} {o}===} {={o}
{========{*} {o}=} {======{o} {o}==} {={o} {========{o} {o}===} {======{o}
{*}===} {={o} {========{o} {========{*} {o}===} {={o} {========{*} {*}======}
{={o} {========{*} {*}========} {={o} {========{*} {o}=} {======{o} {o}===}
{={o} {========{o} {o}} {======{o} {========{*}

I was working with a lot of Brazilian programmers over the summer, and I can't count how many times they brought up churros... I couldn't help it.

It was mostly an excuse to get some Haskell practice in anyway. Using Parsec was a hell of a lot more enjoyable than my last parsing experience which involved magical C++ template meta-programming with Boost.Spirit.

Dang, I need to try writing some Haskell. Good for writing compiler-related stuff. Way better than C/C++ for specific, mostly really technical stuff if you understand it well.

[Geti]

Can you give some concrete examples where that might be true? Almost all the haskell related stuff I've seen has been either easy enough to achieve in any other language or a specific "code toy" to try to make more use of functional features. Got to admit I have a hard time breaking out of a procedural mindset though

[eigenbom]

Haven't written Haskell for yonks, but I remember it was great for implementing toy languages . The AST, for example, writes itself (from some googling):

Code:

data Expr
  = Float Double
  | BinOp Op Expr Expr
  | Var String
  | Call Name [Expr]
  | Function Name [Expr] Expr
  | Extern Name [Expr]
  deriving (Eq, Ord, Show)

Sure you can do something equivalent in C++, but it wouldn't be as terse or readable.

[InfiniteStateMachine]

I've been trying to find justification to learn a functional language like haskell but it's been tough doing anything more than the most basic introductory stuff. It's hard to transition to the point where using a functional language is more efficient than the way I know already.

The most useful example i've heard so far was from a analysis developer who transitioned from c# to f#. He was talking about how transforming data is so much easier in a functional language because it doesn't require defining new structures or classes for each transformation. That seems really useful in some cases.

[TheLastBanana]

@Geti:

Learning about Haskell has been a lot of fun. It's a very slick, terse language, and it's absolutely lovely for data transformations and toy languages.

But yeah, thinking functionally can be tricky. Passing around state can especially get a little painful. I'm nowhere near ready to do anything beyond simple stuff with Haskell, but it's good to have it in the toolbox at least.

[Zack Bell]

SUPER III now has all kinds of moving platforms, both solid and jumpthrough. It has opened up many design/challenge opportunities.

Just sharing my happiness!

[OnslaughtMike]

Finally was able to conquer the task of creating a RESTful WCF web service and consuming it using get and post in Unity3d. This is a task that I've come face to face with before and lost.

[InfiniteStateMachine]

SUPER III now has all kinds of moving platforms, both solid and jumpthrough. It has opened up many design/challenge opportunities.

Just sharing my happiness!

awesome! It's looking better every day :D

@Geti:

Learning about Haskell has been a lot of fun. It's a very slick, terse language, and it's absolutely lovely for data transformations and toy languages.

But yeah, thinking functionally can be tricky. Passing around state can especially get a little painful. I'm nowhere near ready to do anything beyond simple stuff with Haskell, but it's good to have it in the toolbox at least.

Passing around state? Is that sort of how haskell handles mutability? Make a copy of the modified object and pass it around for each mod?

I've always heard the dreaded term monads invoked whenever mutability in haskell is discussed.

[InfiniteStateMachine]

just discovered stblib :D

[standardcombo]

It turns out there's no fall-through in C# switch cases. However, you can do a goto <label>; How about that?

Makes me want to write a program in the old Basic ways, just for kicks.

switch (lineNumber) {
case 0: // main
if (?) goto 1;
goto 2;

case 1:
goto 0;

case 2:
goto 0;
}

Fun debug times.....

[jgrams]

Passing around state? Is that sort of how haskell handles mutability? Make a copy of the modified object and pass it around for each mod?

I've always heard the dreaded term monads invoked whenever mutability in haskell is discussed.

Yeah, pretty much. From an efficiency standpoint it's not bad; you set things up so you're mostly copying references or containers (the structure of the data). But it's both the blessing and the curse of pure functional languages that a lot of things (like I/O and state changes) have to be built into the structure of your code rather than just being function calls stuck in wherever you want.

I think Philip Wadler says it best: "Pure functional languages have this advantage: all flow of data is made explicit. And this disadvantage: sometimes it is painfully explicit."

Monads are basically just a little design pattern: a way to structure your code to hide a part of the boilerplate of passing state around. You might try Philip Wadler's Monads for Functional Programming (the first couple pages of this are well worth reading even if you stop as soon as you get to the code) or Dan Piponi's You Could Have Invented Monads! (And Maybe You Already Have.).

But yeah, as TheLastBanana says, sometimes passing state around is still a pain. I think there are ways to deal with most of it (like lenses for dealing with nested mutable data structures, or the technique of returning/collecting commands/changesets and then applying them to your state all at once), but I don't feel like anyone really gives a good introduction to how you learn to structure practical applications, so it's hard to get into. There's a lot of jargon, which is useful to the people trying to work out the theory of how to make this stuff practical, but a big barrier to beginners.

[Sik]

It turns out there's no fall-through in C# switch cases. However, you can do a goto <label>; How about that?

Wait what, C# has goto? O_O You'd think it'd be gone from all modern languages by now (granted, I have actually found some rather good uses for it when dealing with tons of error handling, but it's so demonized I'm surprised it's still around).

[powly]

only toy languages for kids omit goto

[InfiniteStateMachine]

Passing around state? Is that sort of how haskell handles mutability? Make a copy of the modified object and pass it around for each mod?

I've always heard the dreaded term monads invoked whenever mutability in haskell is discussed.

Yeah, pretty much. From an efficiency standpoint it's not bad; you set things up so you're mostly copying references or containers (the structure of the data). But it's both the blessing and the curse of pure functional languages that a lot of things (like I/O and state changes) have to be built into the structure of your code rather than just being function calls stuck in wherever you want.

I think Philip Wadler says it best: "Pure functional languages have this advantage: all flow of data is made explicit. And this disadvantage: sometimes it is painfully explicit."

Monads are basically just a little design pattern: a way to structure your code to hide a part of the boilerplate of passing state around. You might try Philip Wadler's Monads for Functional Programming (the first couple pages of this are well worth reading even if you stop as soon as you get to the code) or Dan Piponi's You Could Have Invented Monads! (And Maybe You Already Have.).

But yeah, as TheLastBanana says, sometimes passing state around is still a pain. I think there are ways to deal with most of it (like lenses for dealing with nested mutable data structures, or the technique of returning/collecting commands/changesets and then applying them to your state all at once), but I don't feel like anyone really gives a good introduction to how you learn to structure practical applications, so it's hard to get into. There's a lot of jargon, which is useful to the people trying to work out the theory of how to make this stuff practical, but a big barrier to beginners.

Ah thanks for that. I didn't realize reference passing was an option. I'll take a look at those articles.

[standardcombo]

only toy languages for kids omit goto

So Java is a toy language?

[jgrams]

Ah thanks for that. I didn't realize reference passing was an option. I'll take a look at those articles.

Oops. I didn't mean to imply that reference passing was a thing. It's just that since everything is immutable there would be no difference (semantically) between passing the value and passing a reference, so the compiler has no reason to pass by value except for types which would make sense to pass in CPU registers or whatever. Or at least that's my understanding. I admit I haven't done anything significant in Haskell.

only toy languages for kids omit goto

So Java is a toy language?

Nah, Java is a B&D language which thinks it knows better than you.


And to keep this on topic, I'm a happy programmer because I finally got around to trying d3.js, and it's a pretty fun way to make little (or not so little) data visualizations.

[Boreal]

I'm currently writing an interpreter for a custom Lisp dialect for scripting my game, which of course involves writing functions in the native code to be exposed to the script.

Being able to duplicate recursive functions like list using C++ templates is quite cool, and getting functions like display and write to properly show lists felt great.

Of course, I haven't started on the parsing, which is probably going to be the hardest part, and come to think of it implementing procedures is going to be a big hurdle...

[InfiniteStateMachine]

Most of the pre-amble for a fighting game I'm working on is done (virtual input, rendering, state system etc) and the game logic has been going almost TOO smooth.

I resisted the urge to overengineer my solution since this is a fighting game study more than a game and I think it paid off. My code isn't that pretty right now but making massive changes isn't painful at all.

Also glad I setup the gui and console right away, the debugging information I've been able to send to the screen has been very valuable.

[nikki]

Of course, I haven't started on the parsing, which is probably going to be the hardest part,

I've never build a lisp parser myself, but I have read many times that lispparsers are the among the easiest parsers to write (no types, only lists for containers, postfix notation, etc)

here's one: https://www.hackerschool.com/blog/21-little-lisp-interpreter
and here : http://howtowriteaprogram.blogspot.nl/2010/11/lisp-interpreter-in-90-lines-of-c.html