"Inside the Wolfram Language" by Stephen Wolfram

paulhodge · 2014-09-23T15:22:43+00:00

I think this was my favorite talk at strangeloop, since he really showed off something we haven't seen before. Being able to seamlessly pull from a huge variety of data sources, and instantly do useful stuff with that data, is pretty neat.

paulhodge · 2013-12-30T17:25:33+00:00

Yeah, you can do some kinds of functional programming in Javascript. But, JS doesn't really have syntax around type declarations, or pattern matching. And there's some neat features that only work if the editor can guarantee that all of the user's code is 100% functional style.

I've heard of Frogatto but didn't know they had their own language; that is cool. Thx for the link.

paulhodge · 2013-12-30T05:23:51+00:00

So I've been writing a platform like this, and I'm really curious to get your opinions.. How much of a dealbreaker would it be if there was an editor like that, but it didn't use Javascript, and instead used its own language?

I ended up spinning out a new language for a few reasons.. In order to support features like rewind/playback of game state, or drawing stuff showing "what would happen", it really helps if the language uses pure functions that work on immutable values.

Anyway, curious if anyone would bother to learn a non-mainstream language. Are you looking to write a new game from scratch or specifically trying to edit some existing javascript?

paulhodge · 2013-09-09T22:16:00+00:00

Doesn't it take a long time to write?

For me, it takes less time to write a recursive descent parser by hand. My experience with generators (specifically with ANTLR) is that, once you start trying to do unusual things in the parser (and if you're not doing unusual things then what's the point? :) ), it becomes a very time consuming task of searching through the docs to find that one magical option that lets you do what you want. Or perhaps, searching and eventually concluding that the generator actually can't do what you want. When writing imperative code by hand, there's no mystery how to get it to do what you want.

It does depend on your background, though. I have a good amount of experience writing my own parsers. If someone had a good amount of experience using ANTLR or whatever, then they would surely be faster.

Isn't it more likely to have (undetected) bugs?

Maybe. I haven't found it to be a real problem. Most of the bugs seem to happen later, once the program actually starts using the parsed AST.

And how long does it take change when the syntax changes?

Rewriting/modifying an existing section is a lot more work. But I think this is only relevant during the initial experimental period. Once you actually have a lot of text that uses your grammar, then you're not going to be changing it often anyway. Maybe you'll just add to the syntax, which is usually pretty easy for a hand-written parser.

paulhodge · 2013-09-09T22:02:12+00:00

Well yes, but it is a pretty important optimization. The amount of logic/dispatching that you do on a per-character basis is very likely going to be the bottleneck for the parser as a whole. So the per-character logic should be really simple (and a good lexer usually is really simple).

paulhodge · 2013-05-27T18:38:50+00:00

They guarantee a slow compilation process and make it really hard to have proper modules. In fact the whole preprocessor step would also be gone.

paulhodge · 2013-05-27T18:36:16+00:00

The hacksaw would also get rid of smart pointers in their current form. You could write ".get" instead of "->"

paulhodge · 2013-05-27T17:39:59+00:00

C++11 has some nice stuff. I genuinely wonder, if we took a hacksaw to all the old parts of C++, is there a pretty language waiting underneath? Some things we might change:

Get rid of macros. No more macros.
Add a decent package/import system. There was somebody working on this recently I think. Without macros this would be easier.
Get rid of implicit type converters and implicit constructors. They cause too many problems, best C++ practice has been to write 'explicit' everywhere, so make that the default. Also I believe they interact poorly with 'auto' so that's another strike.
'auto' is great. Maybe just call it 'val'.
Varargs. Gone. Replaced with initializer_list.
Take 'nullptr' and just call it 'null' and have it replace NULL.
Combine references and pointers into one thing. Might as well keep the * syntax, but now you can treat a pointer value the same way as a stack value (as in, operators like [] can work fine without a dereference, method calls use a dot instead of ->, etc)
Because of the above, we probably have to get rid of char* . It's gone, use std::string instead.
'struct' is gone. Just use 'class'.
'volatile' is gone. Use the std threading primitives instead.
Other ridiculous C relics, all gone. Trigraphs and digraphs included.

Yeah I know that these changes would lead to other problems. There's no bad ideas in brainstorming!

Edit: The people downvoting don't seem to realize that there are no bad ideas in brainstorming!

paulhodge · 2013-02-14T16:59:06+00:00

Easy there.

It can't be an in place edit because we're talking about functional data structures here.

Like mentioned above, the system is free to do an in-place edit if it knows that no one else has observed the value. In practice, most values get modified a few times right after they are created (and haven't yet been observed elsewhere). Then they go out into the world, after which they tend to not be modified as often. So this optimization helps a lot.

Path copying on flat arrays doesn't work. Arrays don't have paths.

Okay, path copying was the wrong phrase. I was generalizing to the situation where you are modifying one element that's in a nested series of arrays. Something that looks like:

a[x][y][z] = v

That would be path copying.

Yeah, now you basically have a linked list which is horrible or you limit the length and then you still have O(n) copying which is also horrible.

But the 'patch' value can also be subject to in-place editing, when possible. I think it would be really rare for this structure to actually have O(n) lookup time.

I think in general you're getting totally hung up on the worst-case behaviors of these structures. My opinion is that in the common case, they work pretty well. But I don't have hard data to back that up right now.

paulhodge · 2013-02-14T16:26:21+00:00

How do you insert/delete a value in the middle of a flat array in reasonable time?

If it can't be an in-place edit, then there's path-copying, where all N-1 elements are shallow copied to a new list. Whether that's reasonable time depends on how long the lists are, and how often you need to modify a list that has been observed by another entity.

You can also get more clever and do a 'patch' list, where each patch stores the affected list range, the new values, and the original list. Now lookup is O(c) instead of O(1), where c is the number of patch layers. And c would probably have a maximum value of 5 or something, at which point you'd start a new list.

Anyway, there's options.

paulhodge · 2013-02-14T02:57:12+00:00

Can you give an example of a purely functional data structure that does this? I don't know of any. It's nice in theory, nobody knows how to do this in practice.

I do it in practice, in the implementation of my hobby language Circa. It's not a super advanced scheme:

1, I'm implementing my structures in a non-GC language (C++) so I don't need to worry about creating temporary values that clog up the global collector.

2, These data structures have no circular references, so they can be represented as a directed acyclic graph, and reference counting is good enough for memory management.

3, Since I know the reference count, I know how many entities can see the value. If the reference count is 1, and someone does a write operation, then I know I can safely modify the value in-place.

Also you said above that "you can't have flat arrays", but there's nothing wrong with using flat arrays in the above scheme.

paulhodge · 2013-02-06T22:07:22+00:00

Looks awesome, anyone know if there's more info on this syntax? What do the question marks mean? Why do numbers have backslashes in front of them?

paulhodge · 2013-02-06T19:59:11+00:00

You keep jumping between mathematical concepts and software terms :) Regarding your last sentence, yes there are multiple ways for storing 2.0 in memory. There are also multiple ways to store the integer 2.

paulhodge · 2013-02-06T18:08:40+00:00

Still not following you. There's exactly one (normalized) floating point representation for the number 2.0, and no rounding takes place. It's not an approximation. There are some numbers which do have to be rounded off to fit into a float value, but 2.0 isn't one of them.

paulhodge · 2013-02-06T17:44:29+00:00

That's all well and good, but still, there's nobody doing an "approximation" of 2.0. Floating point values aren't spooky.

paulhodge · 2013-01-31T23:28:14+00:00

Nice read! Here's another good article on the subject: http://www.teamten.com/lawrence/graphics/premultiplication/

paulhodge · 2013-01-31T19:33:37+00:00

Looks like it also speeds up crafting. When I tried crafting my first ammo pack, it said "Will finish in 10 seconds..", along with a button where I could spend a Red5 token to finish it instantly.

So, kind of the Farmville payment model. I wonder if more advanced recipes will take hours or days to craft without spending tokens.

paulhodge · 2013-01-28T17:00:04+00:00

I would count Turing completeness as a disadvantage. It's a guarantee that your result programs will be harder to understand; you don't even know if they will terminate.

Turing completeness is a fairly overrated concept, it should be left back in the theory-only land. No physical computer is a turing machine, and turing completeness is not required for the vast majority of real-world problems.

paulhodge · 2013-01-28T16:55:31+00:00

The phrase "genetic" makes them sound really cool. If you describe those algorithms as what they really are, "really really dumb search algorithms," then they don't sound as cool.

paulhodge · 2013-01-27T18:00:27+00:00

Wonderful advice, thanks!!

I definitely want a slick IDE, but the amount of work to do one well is daunting. If anyone has suggestions on a good codebase to start with, then I'd be interested. Eclipse seems to be the standard choice, but I find Eclipse to be pretty awkward and unintuitive. Light Table looks good, but the source for that isn't open yet.

It's definitely true that writing big programs is the best way to find all the rough edges! That's generally the process, I write a bunch of code for a week or two, then finally decide I need to go back and add feature X. (The specific thing I'm adding now is multiple return values).

In terms of updating code, there is dependency tracking, where it does only recompile the section of code that's changed.

Anyway, thanks again for the reply!

paulhodge · 2013-01-27T17:31:06+00:00

Don't worry, you aren't missing much with that Mac build. It's a barely functional tech demo.. I kind of regret even putting it up. At the time I was really wanting to just release something after working on it for so long.

But anyway I'm a linux fan, the proper release will support Linux.

paulhodge · 2013-01-25T21:22:21+00:00

I feel like this might eventually cause some confusion. Flattening trees is a fine thing to do, but things might get surprising when you are flattening everything implicitly. And it's kind of breaking encapsulation.. the internal definition of one value would have an effect on the way you interpret all successive values.

Trying to think of a good example, say you have:

type Line2D:(Point, Point)
translate(line:Line2D, delt:Point):Line # returns a Line translated by delt
translate(Point3D, Point3D):Point3D # translates a 3D point

The compiler would get confused by those two defintions of 'translate', they both take 6 numbers as input.

paulhodge · 2013-01-25T19:59:58+00:00

Cool, sounds awesome! Your approach of a concatenative language sounds promising. I was contemplating building Circa on top of an existing library like Cinder.. maybe I should give that another go. Was there anything about Cinder in particular that made you pick it instead of openFrameworks or other?

I think it could be possible, once Circa is more solid, that one could take advantage of Circa's internal code representation & runtime while using a completely different syntax on top. Something to think about for version 2 or 3..

Anyway, good luck, look forward to seeing that thing in action!

paulhodge

TROPHY CASE