The State of Limit Theory Development, 2017 Edition!

Read and discuss the latest big updates in the development process.

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

Postby lensman » Fri Feb 24, 2017 1:53 pm

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!
lensman
Recruit
 
Posts: 3
Joined: Fri Feb 24, 2017 1:27 pm

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

Postby lensman » Fri Feb 24, 2017 1:58 pm

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.
lensman
Recruit
 
Posts: 3
Joined: Fri Feb 24, 2017 1:27 pm

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

Postby Flatfingers » Fri Feb 24, 2017 5:26 pm

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?
User avatar
Flatfingers
Vice Admiral
 
Posts: 4475
Joined: Sat Nov 24, 2012 12:45 am

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

Postby 0joshuaolson1 » Fri Feb 24, 2017 9:16 pm

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?
0joshuaolson1
Recruit
 
Posts: 7
Joined: Thu Feb 02, 2017 11:25 pm

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

Postby BFett » Fri Feb 24, 2017 10:13 pm

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.
User avatar
BFett
Vice Admiral
 
Posts: 2425
Joined: Thu Jan 23, 2014 6:44 pm
Location: A galaxy far far away

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

Postby 0joshuaolson1 » Fri Feb 24, 2017 11:15 pm

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.
0joshuaolson1
Recruit
 
Posts: 7
Joined: Thu Feb 02, 2017 11:25 pm

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

Postby Cornflakes_91 » Sat Feb 25, 2017 7:27 am

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:
User avatar
Cornflakes_91
Admiral
 
Posts: 9033
Joined: Wed Mar 06, 2013 1:53 am
Location: Austria

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

Postby Dinosawer » Sat Feb 25, 2017 7:32 am

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
User avatar
Dinosawer
Admiral
 
Posts: 5620
Joined: Fri May 09, 2014 1:08 pm
Location: Belgium

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

Postby SonarBeserk » Sat Feb 25, 2017 12:25 pm

Like scratch?
-snip-.[/quote]

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.
SonarBeserk
Recruit
 
Posts: 2
Joined: Tue Feb 21, 2017 7:15 pm

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

Postby BFett » Sat Feb 25, 2017 1:17 pm

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.
User avatar
BFett
Vice Admiral
 
Posts: 2425
Joined: Thu Jan 23, 2014 6:44 pm
Location: A galaxy far far away

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

Postby Dinosawer » Sat Feb 25, 2017 2:33 pm

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:
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
User avatar
Dinosawer
Admiral
 
Posts: 5620
Joined: Fri May 09, 2014 1:08 pm
Location: Belgium

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

Postby Silverware » Sat Feb 25, 2017 2:36 pm

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:
ᕕ(ಠ‸ಠ)⊃━☆゚.*・。゚
Image
User avatar
Silverware
Vice Admiral
 
Posts: 2785
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

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

Postby lensman » Sat Feb 25, 2017 6:33 pm

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...
lensman
Recruit
 
Posts: 3
Joined: Fri Feb 24, 2017 1:27 pm

Previous

Return to Announcements



Who is online

Users browsing this forum: No registered users and 4 guests