Interested in doing some further things

General JUCE discussion
1

Aside from the addition of a multitude of algorithms and graphical contextual pieces as is provided by tools like flex/silverlight, I have a suggestion - and since you all have been doing the stuff I was going to do anyway, I may want to start helping when I have some free time too…

Why don’t we create a fork of this to provide a new means of application delivery over the internet? i.e. everything going forward is going to be coming from some form of app store. With something like this, you could guarantee that the compiled app is a secure application, which doesn’t allow for reading/writing to files out of it’s assigned areas, doesn’t transmit information to servers that compromises identity or information leakage, etc. e.g. the user downloads an app that is nearly guaranteed to be secure, and it only transmits its own data - without access to data from other apps or parts of the os that it isn’t assigned, or writing to files that it isn’t assigned to write to.

Since it would be compiled under your own logic, this could be accomplished. Which is basically where I was wanting to take a programming language - as a new form of application delivery that could promise the capabilities of the internet, a lean-and-mean running environment, without the nastiness and leakage that the internet currently has. Then it’s on the operating system to do the rest of the privacy work, as it should.

The current internet does well in delivering information and applications, but does rather poorly in finding authoritative, accurate, or personal but very credible information. Also, it’s a lackluster platform at delivering applications that provide full capabilities of any os. personal media, blogs, information, and publications are very difficult to find on any topic unless you are looking for the person writing it - which defeats the purpose. For companies, certain companies are given preference just because we have an ordered generic search list. It sucks. Applications are insecure, unstable, perform poorly, have a multitude of bugs and security holes, leak information that shouldn’t be leaked, etc. That sucks.

These types of things could be solved by expert programmers putting the necessary platform and tools in place to solve the underlying problems of the internet. We would just need to sit down and figure out what needs to be done, but it can be done with something like this.

let me know your thoughts…

1 Like
2

lol - it says JUCE weenie… I’m a programmer with a beard at 30… :slight_smile:

3

Reefer-induced idealistic stream-of-consciousness rambles are always welcome on this forum!

But hey, if you really have got some kind of achievable plan for a better app delivery system than nobody else has yet invented, and if it somehow relates to JUCE, then please let us know exactly how it would work!

4

I think what you really want is a a JUCE Native Clent or Emscripten backend.

5

Sorry for the insult-to-insult. I’ll retry this:

Forget for now what I had to say late at night after a few beers and some car-dreaming…

Take a look at what people are doing with rapid application delivery in the areas of mobile development - what is popular and why it is popular. The fact is, you guys have the best library for native development out there. It’s a shame you aren’t more popular. That said, there’s some things you can do that some other people are doing right now that would improve your user-base as far as programmers…

For example, you could fork this language into a different one, based on web-like feel of programming. The fact is, other programming models are much faster than c++ straight-away. Sure, c++ is the good guy language, but bleh, programmers doing these cross-platform things would likely want to use a cross-platform feeling language at a higher level. That means something that feels more like a new language, and not and old language. Otherwise, doing to c++ what jQuery did to javascript is the alternative - which is kind of where you are headed anyway.

So in other words, take a look at what other people are doing with cross-platform development - like AppTitanium, etc. It still runs natively, only you’re not programming in a native language. That’s what people are looking for out of a new cross platform toolkit - something that runs natively and uses native components on iOs, Android, Symbian, WIndows, Mac OSX, Linux, BSD, etc. That doesn’t mean you can’t provide system-specific functionality for things that can’t be abstracted. It just means they would prefer to code as little system-specifics as possible, while utilizing what can be abstracted in a very efficient code-to-release cycle. In this age, it’s all about turn-around time, and we want to code in a way that makes us not only better coders, but more efficient coders. You have to remember that a lot of people out there aren’t that skilled. You can make up for that lack of skill by providing them a platform that’s both rapid-development and takes care of the underlying problems inherint in normal c++ programming. Bugs, security holes - you could put a stopper to that while also providing people with a rapid code style…

So what I’m saying here is consider how you can build on your already comprehensive and stable environment into a faster-to-release and rapid-development style of programming. Then consider where we are going with things. Developers are having a hard time making sufficient money out of app stores; but the benefit of app stores should be that the os can have an easier time securing the platform. This is also something you could do yourself, by signing apps that are compiled, built, and distributed using only your code base. In that sense, you would have to fork into a differently named toolkit and take them down separate paths so you don’t accidentally disturb what you just did with JUCE. It doesn’t need to run on top of a runtime - it just needs to be ensured that it was built using your layers of abstraction and nothing else. That can be acheived with code-signing, elimination of functions that could be a potential danger to the underlying system (i.e. recognizing what type of code could be used to do something unwanted and limiting that functionality) and so in a sense you would be ensuring that since we can verify it was built by our system, and checked in to our repository, and the access controls that it requests are verified by us, we can more easily ensure 1. what the program will do and have access to and 2. to the user this means it is safe to use/doesn’t do anything unwanted. It would take a lot of planning, but is essentially what the people creating operating systems should have done anyway - and also a kind of model that they might move towards in native development, anyway. Just a thought if you wanted to take things furhter.

For now, ignore that crap and just take a look at what other people are doing, see what they are doing right, what they are doing wrong, and consider where you want to take your newly stable and robust c++ library. Do you want to do something like jQuery did with javascript and stop? Or do you want to make it a platform for rapid development and gain popularity? Or do you want to build a platform in which application delivery, access controls, data transfer, authentication and authorization, security, privacy, etc. are all taken care of by you? Or all of these things? Just questions you all should probably be asking yourselves at this point.

The reason I say this is that you have this wonderfully built c++ library. So what? I could have done that if I had enough free time. I’m a busy guy. Where do you want to take it, and what do you want to do with it that is really going to set it apart from the crowd? That’s what I want to know.

6

Dreaming in a car after drinking beer? Hopefully you were a passenger, not the driver.

Of course you could. It’s not difficult at all. I only wrote one because I had lots of spare time to kill, and nothing else to do.

I do actually have a secret project underway that I’ll be announcing soon, which I might make a big splash in the world of c++. No new web-style programming languages involved though, I’m afraid.

7

I have to say that after being several times involved with companies that were going to transform the Internet, I’m deeply skeptical.

There are really two issues:

  1. The technical problems associated with what you’re proposing are daunting. We’d need at least another full-time Jules (and then we’d need another full-time Nataleigh and then the Clone Board would get on our back).
  2. The technical issues are as nothing compared to the issues of trying to get people to use your fancy new thing.

If you were serious, the way to start would be to create a “clever demo” that just sent one “piece of program” from one spot to the other, and then use that to rile the geeks (that’s us).

8

Of course I was the driver - this is America, you British nutmeg… :slight_smile:

Now there’s something interesting. I’ll wait to see what you all do with it. I have other projects that nobody is really doing right now that I want to get done. Then I’ll see where these different languages end up and see where I want to take things. After all, I can always build an abstraction on top of JUCE and show it to you guys before I’m done. It’s really not that difficult the way I see it - and it may be better if I showed you what I meant rather than trying to type it all out and convince people that it should be done. All I’m doing at this point is looking at things and seeing ideas. That’s not to say it’s a good freaking idea… or that it would catch on. Or that it would be better left to the OS designers. But we kind of need to see where OS’s and mobile devices/platforms are going to take things first. Right now, I see a lot of people hoping they can just build web-apps for all these things. Except web-apps in my opinion kind of suck…

[quote]1. The technical problems associated with what you’re proposing are daunting. We’d need at least another full-time Jules (and then we’d need another full-time Nataleigh and then the Clone Board would get on our back).
2. The technical issues are as nothing compared to the issues of trying to get people to use your fancy new thing.[/quote]

I personally don’t think the complications are all that difficult, and it can evolve as you go. It may seem complicated getting into it, but once you mash out the details you’ll see the most complicated thing is involved with ensuring that code was in fact compiled under your own tool - so you can place automatic access controls on the app without having to rely on something like apparmor. I am really again thinking these sorts of controls should be handled at the operating system level.

As far as providing default functionality - consider this: hackers, etc. - many of them use built-in tools or scripts to accomplish what they are doing. On our end, we specify best-practices and techniques that are largely up to the developer to implement, where most people either don’t listen (look how long we’ve been beating some of these drums), or mess it up, and/or largely ignore groups like black-hat when attempting to actually secure anything. Providing people with functionality up front that they can easily implement is what I am talking about there - and that’s not complicated either, really.

And yes, there’s the problem of getting people to use it - which is why this is the last project on my to-do list. It would generate the least amount of revenue, take the greatest amount of work - of which I don’t have enough free time to really perform, and if it flops it was a complete waste of a lot of my time…

I don’t think my goal would be to transform the internet, necessarily, but rather enhance the capabilities of the internet…