Return to “Announcements”

Post

Re: The State of Limit Theory Development, 2017 Edition!

#211
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].

[1] https://golang.org/doc/go1.8#gc
[2] https://golang.org/pkg/runtime
[3] http://stackoverflow.com/questions/6125 ... ons-from-c
[4] https://golang.org/cmd/cgo

That's it from me! I hoped that information helped you in one way or the other. ;)
Thanks for all your obviously very hard work!
Post

Re: The State of Limit Theory Development, 2017 Edition!

#213
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?
Post

Re: The State of Limit Theory Development, 2017 Edition!

#214
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?
Post

Re: The State of Limit Theory Development, 2017 Edition!

#215
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.
Image
Post

Re: The State of Limit Theory Development, 2017 Edition!

#216
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.
There's Blockly, but maybe code can be contextually refined/refactored with a library of software patterns available through an IDE personal assistant?

How would one make arbitrary design constraints and using Twitter APIs easier to understand by visualizing them, though?

* Whoops, imagine 'library of software patterns' links to stuff like proxy patterns, dependency injection, promises, etc.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#218
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.
Like scratch?

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.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: The State of Limit Theory Development, 2017 Edition!

#220
Cornflakes_91 wrote:
BFett wrote: I would love it if writing an if loop was as simple as creating a new layer in Gimp.
ifs arent loops :ghost:
Replace if with for and while. At any rate, I still think that there is an undiscovered method for programming which would boost productivity ten fold.
Image
Post

Re: The State of Limit Theory Development, 2017 Edition!

#222
Dinosawer wrote:
BFett wrote: At any rate, I still think that there is an undiscovered method for programming which would boost productivity ten fold.
We eagerly wait until you invent it.
Might wanna learn how to program first though
:ghost:
It's the fabled Fourth Gen Programming Language BFett is asking for.
The magical space-otters havent deigned to come down and reveal the fourth gen language as of yet mate.
:ghost:
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: The State of Limit Theory Development, 2017 Edition!

#223
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.

(yawn)... better hit the hay I think...

Online Now

Users browsing this forum: No registered users and 4 guests

cron