@ikerms: Qt Creator has that and I'm using it daily. It's a great feature, and I'm adding it to my editor (once I solve the smooth scroll that is).

@ikerms: Also in Vim: "/\u" to jump to next uppercase "?\u" to jump to previous uppercase (bind it to whatever shortcut you want) and in Emacs "C-c C-w" to toggle the subword movement mode ("words" are now separated by uppercase characters). You know... if you wanted to join the dark side.

ust annoyed at the fact that I can quickly move to a name like calculateCurrentPosition but if I want to change it to calculateFinalPosition I can't just quickly erase the middle word by using caps as stop points..

you can do that in vanilla vim by typing (no, I'm not kidding :) ): fCctPFinal<esc>

(from normal mode)
fC - move to next C
ctP - change the text from here until P
Final - the word you want instead
<esc> - go back to normal mode.

There is also a plug-in to make it easier. Vim - powerful but cryptic...

midnight_mero
Maybe not the place to ask, but has anyone thought of (possibly radical) new approaches to editing code?

Yes I have. I have made a prototype where you dont need a keyboard, and where statements are considered like essential building blocks. A bit like lego. The "language" is graphical.

"XOR EAX EAX" is an instruction that is a constant, kind of. From the point of view of the coder, it is a basic building block. "mov eax, imm32" is a bit less "constant", but it still has only one parameter, and if this is defined already, it can be put in place with a click, avoiding typing it.

By using a graphical interface, as opposed to a text interface, you can avoid ALL the problems of text in code. Which often turns out to be parsing problems. So by using graphical objects, all parsing is just nullified.

In addition to solving lots of non-obvious problems, it also means you can name an instruction, or a routine, or a class or a module, anything you want. They could even share names, at no conflict (for the compiler).

This will allow the syntax to have a much larger "resolution", just like a graphical image have higher resolution than a textonly screen.

In the true code, no names exist. Only in the source do they need to exist. Also, syntax is just a wrong consept, as the machine has no syntax. It just eats strings of bytes.

So therefore, in my prototype, syntax can be selected 100%. Which means you can rename RDTSC to ReadTimeCounter if you want. Or you can rename "mov eax, MyLongConstantNameInChineese" to "EAX == PlingPlongPlang-tang-clonk". Such that you can have an assembly language with C syntax sugar. So the source is readable for humans, but also extremely readable to the CPU, at the _same time_, which makes for compile-times, unheard of.

I also plan on creating a virtual assembly syntax, that is 1) can be fully userdefined, but has a default syntax. 2) can be mapped to a target CPU file, for possibly porting between OSes.

Now, its just a prototype. And fact is I would be happy if someone else would write the real thing. I want it ready for my phone, at the time I get to the nursing-home:)

I can compile a small windows program at the moment, but I need to rethink the interface, because unless I can make it more efficient to use, then Casey uses Emacs it will not deserve to become something real.

Kladdehelvete

midnight_mero
Maybe not the place to ask, but has anyone thought of (possibly radical) new approaches to editing code?

Yes I have. I have made a prototype where you dont need a keyboard, and where statements are considered like essential building blocks. A bit like lego. The "language" is graphical.

Oh, you mean scratch?

sol_hsa

Oh, you mean scratch?

I do not understand what you are asking. But since your input on direct sound and directshow, my working assumption is that you do not even know yourself.

And that's perfectly fine =)

[quote=midnight_mero]Maybe not the place to ask, but has anyone thought of (possibly radical) new approaches to editing code?

https://www.youtube.com/watch?v=8SkdfdXWYaI

Kladdehelvete

sol_hsa

Oh, you mean scratch?

I do not understand what you are asking. But since your input on direct sound and directshow, my working assumption is that you do not even know yourself.

And that's perfectly fine =)

Scratch is a programming language that's graphical, you drop in blocks that tie together etc. Like lego. Like the language you described.

As to your "working assumption", I'm not quite sure what you're talking about.

Sorry, I have overlooked your question.

I guess Casey won't go for full Unicode, as he mentioned to use bitmap fonts for rendering, so I guess the Unicode support will be somewhat limited if not non existent (I don't think there's gonna be a lot of text in the game).

To start, you perhaps can do the following: Casey showed how to load a BMP to memory and how to render it. You can use that to load a bitmap font. You can then draw only a part of that bitmap depending on what character you need to draw. You will simply render character by character, incrementing the X by the character width. That's the first beginner way Casey will probably go for when it comes to rendering a bitmap font.

@martincohen, @BlueWolf & @rathersleepy : Thanks! I´ll give those options a try.

midnight_mero
Maybe not the place to ask, but has anyone thought of (possibly radical) new approaches to editing code?

Obligatory Bret Victor:

https://www.youtube.com/watch?v=8pTEmbeENF4

There are a lot of radical approaches, but most of them are not as new as you might think.

Thread did not disappoint.

@Kladdehelvete

This is what I was hoping someone would say. I feel like most visual programming I've seen is in the realm of toy / education. Things like scratch or lego mindstorms come to mind (as sol_hsa mentioned). I don't know anything about it, but someone in the stream mentioned blueprints in the unreal engine which might hint at a more practical application. (There's actually quite a bit more examples of this than I realized).

I think part of the problem with visual coding is twofold:

1. Code doesn't exist in a vacuum. It has to interact and integrate with existing code, most of which is already written in text.

2. It's hard to match the effectiveness of keyboard input, even if the keyboard input is still entering every character by hand. Maybe it's unavoidable math: 10 fingers adds up to a whole lot more potential input than 1 mouse cursor.

I think if an alternate interface is going to challenge traditional text input, it's going to have to have support a large baud rate (as it were) of information from human to computer.

I'm curious what the research playing field looks like on this front. Any HCI people around with insight? (One can hope.) :wistful:

@sinsizer

Wow, that's neat! That gives me this crazy vision of programmers with like two hands directly on the screen dragging stuff around minority report style, speaking in a strange language of clicks and grunts, with like an airplane rudder foot-peddle system on the floor and a string from each elbow tied to different-sized hi-hats. :silly:

[Of course, it's at this point I usually think: "yeah but programming is not really even very limited right now by inputting information. You spend most of your time thinking anyway." But I'm not sure this is entirely true all the time... what do you think: is there still quite a bit of time just spent translating thoughts to bits?]

Interesting insight when he said (@15m) he optimized for the low level stuff: character twiddling, search, jump and that sort of thing, "the things you spend most of your time doing." Another thing to learn from this video is the best way to make sure any new type of input you're designing is as effective as possible is to actually use it all the time.


@Pseudonym73

Thanks for linking that great talk! That's in part what prompted my question, actually. I love Bret Victor: "There is no 'Technology'. There is no 'Design'. There is only a vision for how mankind should be, and the relentless resolve to make it so."

To deliberately miss his point a little, a short aside: It's common (and probably mostly true) to believe the things we use today have survived because they're the most effective. And other experiments met their inevitable end along the way because they simple weren't better. But I think things are still changing quickly enough that a twist on something that didn't take off 40 or 30 or even 20 years go might have potential on the modern landscape.

(Total tangent, I feel the same way about rendering. So much of the way games look these days is an artifact from the days of trying to squeeze out as much computing power as possible from limited hardware. We've taken that to the extreme while still, as though from inertia, striving for realism. But what completely other kinds of ways can we make things look? Lot of great stuff out there, I'm optimistic!)

Ah, well, it's fun stuff to think about, anyway.

The big inspiration for my question was a little ("pie in the sky") rant along these lines Casey had in (I think) the emacs tutorial prestream, but I think that might be pie in the sky (or dust in the wind) itself, at this point. :side:

Yes I have. I have made a prototype where you dont need a keyboard, and where statements are considered like essential building blocks. A bit like lego. The "language" is graphical.

I'm working on something similar. Do you have a screenshot of it?

midnight_mero
Thread did not disappoint.

@Kladdehelvete

This is what I was hoping someone would say. I feel like most visual programming I've seen is in the realm of toy / education. Things like scratch or lego mindstorms come to mind (as sol_hsa mentioned). I don't know anything about it,

I take a look then. But there nothing "toy"-like to my tool. It is editing the binary more or less directly, but in memory. Using a kind of virtualization of code and data, for the RTD to have control.

The reason for a graphical interface, is that it allows for much larger space of "syntax" selection. Also it allows for a large space of signaling the coder of what is actually happening to his code. De-coupling the syntax from the binary has many non-obvious benefits.

One that would be that I could read your code in my syntax. Another is compilerspeed, and yet another is complete typechecking, and even codechecking by the compiler nanoseconds after an instruction is written.

One of the most important features of a tool the way I see it, it to be able to get to everywhere in the code, from everywhere, as fast as possible. One of my goals is to try to make this efficient. Unless I think I succeeded, I will not publish anything.

midnight_mero

but someone in the stream mentioned blueprints in the unreal engine which might hint at a more practical application. (There's actually quite a bit more examples of this than I realized).

Just a couple of month after I wrote my prototype I witnessed the demo of the unreal engine, and I immediately got excited seeing that they had been thinking a little bit along the same line, with the Blueprints. I even think, to my self, in private, I must have gotten some inspiration from them, somehow. Even though I was disconnected for 4 month, at the time I wrote my prototype. I am unable to express what that feels like, but I guess some will get it, and to others it will sound crazy.

I have always admired the Unreal team, since it was pretty obvious already in their first works they knew how to make games that was fun to play and performant. It's typical almost, how simple a program looks, is often felt like the illusion that it was easy to do, whereas it's always the other way around. When a program feels efficient and fluent, it means it took extremely much effort to get it that way. Or at the very least a lot of competance.

The demo was amazing. But 3D games are not for me, since I figure that the content creation is the most demanding task. Way over my competance and capacity, and what excite me the most is coding.

Plus there's only so much time in a year, and one has to figure out a niche to fit into. There's so many good coders out there, it seems, that even if the market screams for more(according to Casey), the true market is overflown by software.

I mean, even if you could launch a new facebook tomorrow you'd be wasting your time.

There now so many great games out there, that it's impossible to make time to play even a small selection. If you're not able to compete with the very best, you are likely to waste precious time and resources for nothing.

99% of games on googleplay, do not make a dime.

midnight_mero

I think part of the problem with visual coding is twofold:

1. Code doesn't exist in a vacuum. It has to interact and integrate with existing code, most of which is already written in text.

This is true. But there's nothing preventing you from interacting with the same code, in the form of a binary library. Which my tool does already, calling to the windows library for having a window.

But the tendency among matured coders is to avoid libraries as much as humanly possible, since it in many cases is trivial to implement the few functions you would need, and that for libraries that have some serious scope, the applications already exist. So there no need to use them, since the solutions are already out there. When you want to create something new, there isn't a library to call to.

midnight_mero

2. It's hard to match the effectiveness of keyboard input, even if the keyboard input is still entering every character by hand. Maybe it's unavoidable math: 10 fingers adds up to a whole lot more potential input than 1 mouse cursor.

This is very true. I completely agree. A keyboard is even more efficient than speaking. Not just a little more efficient, but the difference is so huge that I doubt that "talking to a computer" will ever gain popularity, just like talking to a dement never will be much fun. For creative people. FLOW FLOW FLOW is everything. During FLOW, you can in two month do the work equivalent of _SEVERAL YEARS_ of coding without it. And it requires that you can work at the speed of thought. No, even faster then the speed of thought. You need to go at the speed of your sub-consious thought. When Paul Graham speaks about good programmers, I tend to think along these lines. That this is those that have coded so much, they can connect directly with their subconscious while coding. They are no longer coding, but "dancing".

midnight_mero

I think if an alternate interface is going to challenge traditional text input, it's going to have to have support a large baud rate (as it were) of information from human to computer.

I strongly agree with you here. This is the main issue to solve.

d7samurai

Yes I have. I have made a prototype where you dont need a keyboard, and where statements are considered like essential building blocks. A bit like lego. The "language" is graphical.

I'm working on something similar. Do you have a screenshot of it?

I could produce one, but I dont see any reason to. Following the Handmade series has tought me many new ways in which I could implement my interface, way more efficient.

I already knew from before that it would need to be rewritten. At first I was focused on making the code compile and run. And this took so much of my focus, that I didn't really stop to think that it also would have to be efficient to code with.

I tried imageshack but I need an account. I also need to get good looking images and all of this takes time. And since it in anyway will change a lot I don't think it would be worth it.

But basically each instruction is a box that can be zoomed in and out. You could zoom out to see the entire structure of the code. And you can zoom in to view an individual module, class, function, struct, dataobject or instruction.

In my tool, making a datastucture virtual, static, or dynamic is just a matter of clicking the datastruct, and then flag it as this or that. Arrays, and list can be created in two clicks, from a known base type. Input to static data, are given by spesific editors targeted at the type. If the type is a float, then the inputeditor is a calculator.

If you zoom close to an instruction you would see its Target CPU instruction in a smaller font at the top. In the middle is the virtual instruction syntax. And at the bottom, in a smaller font, is the hexadecimal string. When you zoom out again it takes the height of the userselectable font, and takes up the same amount of space as it would do in a texteditor. And then it shows only the virtual syntax.

But in short, right now it's unpractical to use, and just a prototype, that may never see the daylight. And if someone else already has created it, I would prefer to use that tool instead, unless it was extremely expensive.

But if you already have pictures of your work, that you would like to show, then I be happy to see them. And maybe if you do, I will post some shots myself.