Display posts from previous

Sort by

JoshParnell wrote:[Go is] one of the only major languages that I haven't given time to yet. I do need to check it out (although IIRC GC may be an issue here as well).

(long time lurker, made an account just to chime in here)

I have, let's say "moderate" experience with Go. Coming from C++ and plenty of Python coding mostly thingies talking to each other (no interference from pesky humans), Go is quite pleasant to work in. It's syntax reminds of python, e.g. parens used sparingly and the code usually comes out succinct and easy to read.

Performance-wise I'd say it's in the range of "quite good" (comparing to C++). Its concurrency is quite wonderful; spawning "goroutines" left and right, actually by the thousands is no problem as they're not system threads.

Regarding GC, in the context here it's probably important to note that its GC is optimized for short collection time, which they now (in 1.8) brag to be "usually less than 100µs"[1] (no, not ms). Unfortunately, there is very little control over how the GC does its work [2].

That being said (mostly positive, I suppose), a major showstopper could be that there currently is no nice (for some definitions of nice) way of calling Go from C/C++[3], which I suppose is the way you'd like to do it. The other way around is quite easy, however, and even supported by the standard library[4].

Oh, and another thing: Go has no generics. This might irk a seasoned C++er, but I haven't been too much bothered by it. That the internal containers (array, slice and map) are kind of genericy alleviates this problem slightly.

So here's a typical Flatfingers-dumb question: why is there such a profusion of Algol-derived languages today?

We seem to be in a period, not unlike the '80s, when a bounty of new boutique languages is sprouting. And yet, all of them, compiled or interpreted, are easily distinguished as Algol descendants -- just in mildly different flavors. If you know C, you can easily pick up Python, or Go, or D, or Java, or ECMAScript, or pretty much anything except LISP. And maybe INTERCAL. OK, yes, probably INTERCAL, too; it's the duckbilled platypus of programming languages.

This provokes an idea inside my noggin: if all these languages are cognate, is there some ur-language of which they are all naught but faint adumbrations? Less poetically, as we explore a lot of variations on Algol descendants, is it conceivable that all of these are really only slightly different instances of a single universal computer programming language that is somehow just natural to the brain of the human programmer? (That isn't actually Algol itself.)

Long-time forum participants (and deep lurkers) will remember when Josh waxed enthusiastic about somehow getting away from the text paradigm of programming. There was his devlog of Oct. 22, 2013, as well as a thread on Visual Node Programming that emerged from Josh's astonishingly beautiful graphical node editor, including a brief mention of the NoFlo Kickstarter project.

Are these ever going to happen? Or will the future of creating software be a convergence on One Text Language to Rule Them All?

Flatfingers wrote:Are these ever going to happen? Or will the future of creating software be a convergence on One Text Language to Rule Them All?

Until we can program with our brains instead of eyes (or ears)/hands (or eyes), we're kinda stuck with languages, which have to favor paradigms or be favored by certain advocates to stay relevant. Do we really want Scala 10.0.1, or SuperArrowMetaHaskellTriplePhDFork, or ClojureEveWithGraphicalNixVersionControl?

What I'd like to see is a programming environment that is as easy to pick up as Gimp is. Something with built in functions and menues to call up other functions which snap together. I would love it if writing an if loop was as simple as creating a new layer in Gimp.

I think programming has become too wordy and things actually need to be visualized so that mental limits aren't hit at the ~100,000 line mark.

BFett wrote:What I'd like to see is a programming environment that is as easy to pick up as Gimp is. Something with built in functions and menues to call up other functions which snap together. I would love it if writing an if loop was as simple as creating a new layer in Gimp.

I think programming has become too wordy and things actually need to be visualized so that mental limits aren't hit at the ~100,000 line mark.

BFett wrote:What I'd like to see is a programming environment that is as easy to pick up as Gimp is. Something with built in functions and menues to call up other functions which snap together. I would love it if writing an if loop was as simple as creating a new layer in Gimp.

I think programming has become too wordy and things actually need to be visualized so that mental limits aren't hit at the ~100,000 line mark.

Nice for learning programming, but the thing is, once you can actually program doing it by typing is waaaaay faster and easier than using menus and stuff.
The hard part of keeping programming in mind isn't the words - the words are easy. The hard part is the actual logical underlying structures you're building. How you visualise it can help understand how small scales work (which is why colour themes for IDE's are a thing), but doesn't help for the big picture.

Technically speaking scratch is build on blockly which was mentioned before. And visual design languages seem to work well about up to where you want to do something not planned for and it falls on its face.

Flatfingers wrote:Are these ever going to happen? Or will the future of creating software be a convergence on One Text Language to Rule Them All?

I'm of the conviction that no programming language can even "cover all bases". If the language is so generic that is is suitable for every task it, in fact, end up being useless for all. There will always be tailored tools for specific tasks. As an analogy we can take any other profession that uses tool. These professions are likely older software enginering , have their tools evolved to "on tool to rule them all" ? No.

Similarly also in API design; if the API is so flexible and generic that all functionality it wraps is available through it, it (again) ends up being useless, and even pointless. In my view, for an API to be "good", it has to be simpler than the functionality it wraps, otherwise you've gained nothing, and can just as well use the "unwrapped" functionality directly.

But specifically about flow-based approaches. They're probably useful in some contexts. I haven't personally encountered that context yet. At least not in programming. For audio and video processing, sure, good use cases already exist.