I think this is due to the fact that not every has ability / desire to live in the console. Having a development process that can work without a compile step is important.
Run it for every project you mean. The nice thing about the web is that with a simple http server you can just start coding. Compile-steps take away that incredible advantage.
Yep. Is that so bad? You know you can have multiple Terminal.app's open at once, right?
> The nice thing about the web is that with a simple http server you can just start coding.
The nice thing about browserify/node is that I can install node, clone my seed script, execute it, and just start coding.
> Compile-steps take away that incredible advantage.
While giving you the huge advantages of TDD/unit testing; the npm repository; being able to use the CommonJS module pattern...
If you're just woodshedding a toy, or trying to learn - by all means, set up lighttpd and boot sublime and go at it. But if you're trying to build production-quality software... hone your craft; be better than a codemonkey.
> While giving you the huge advantages of TDD/unit testing
You don't need a compile step to do unit testing. Or even to use CommonJS for that matter.
> If you're just woodshedding a toy, or trying to learn - by all means, set up lighttpd and boot sublime and go at it. But if you're trying to build production-quality software... hone your craft; be better than a codemonkey.
You don't need a compile-step in development to create good software. Client-side loaders have all of the advantages of server-side loaders but you can also use them without a watch task. ES6 modules are just going to make it all easier.
> You don't need a compile step to do unit testing.
Okay, I guess I could have a window with karma open and keep refreshing it every time I change code. Having an eshell open running my unit tests every time I save is a lot faster, though. Unfortunately, most of what I do is remote over SSH instead of having a local development environment. And that doesn't even begin to cover building a jenkins (or other CI) script to run your non-compile-time unit tests.
> Or even to use CommonJS for that matter.
Which client side loaders would you recommend? I've used AMD/RequireJS in the past and its headaches were not worth the benefits. The only other project in the running is Webpack.
> but you can also use them without a watch task
I suppose I don't understand the watch task hate. It's there. It runs. It versions my build. It lets me know when I've saved something stupid. It's faster than tabbing to a browser and going through the steps to reproduce the iota of code I just wrote, or refreshing a testrunner page.
How do you do continuous integration and save-time unit tests without a preprocessing step without tying your project to a bloated IDE?
> ES6 modules are just going to make it all easier.
When ES6 modules come around to being available in IE9 (or IE9 finally dies), I'll believe that you can do all this without a processing step. Even when ES6 modules become available in modern browsers, you'll still have to run everything through a preprocessing build step to get backwards compatibility. And woe to whomever tries to do dynamic dependency loading on mobile... that 200-2000ms per-http-request overhead on 3G will bite you right in the bounce rate.
This language was written by a professor of mine Ge Wang, also the founder of Smule.
He likes to refer to it as "strongly timed", and I think it is a really accurate description. While the language does have limitations, it can also be beautifully expressive for certain things.
If anyone has any question for the author please let me know and I'll either get him to come in here or be a surrogate and answer directly
I don't have the time to investigate the language, but I wonder if its semantics borrows from synchronous programming languages such as Lustre [1], Esterel [2], or Signal [3]? Those languages were designed to program discrete controllers and embedded real time systems, and they have a very strong notion of timing and scheduling (via typing) in their semantics which allows to prove functional properties such as accessibility of states, liveness, time and memory bounds, etc. using formal methods such as model checking.
When I was doing my master thesis on this domain, another student in the lab (who was from an IRCAM [4] master degree) worked on the use of synchronous languages to follow a musician who plays at arbitrary speed a given music score (or something along those lines). It was quite fun!
I've completed the ChucK course on Coursera. As far as I can say, it doesn't borrow semantics directly from synchronous programming languages though it may parallel them. Syntactically it's similar too Java/C++.
Time/Duration are data types, and you must advance "now" to generate samples and events.
that's such a nice term, "strongly timed". It seems like the correct term to use for programming languages in which time is reified and in which one can make declarative statements about time and events.
The authors post reminded me that I had not upgrade my linode from 24GB to 48GB and I went ahead and did it. Then I realized that I had originally been in the ssd beta. I messaged support to find out the beta had recently closed, but the support agent did say this.
Totally not ideal... but if you are looking to hack together a simple client side webapp that uses api's that do not support cors or jsonp you are not left with much of a choice without having a server side solution
For development we use grunt-connect-rewrite. It is a middleware for connect (which yeoman uses) that allows you to write custom rules similarly to how you would implement them in Apache.
Thanks for the heads up. I'm taking a signal processing class at the moment (https://ccrma.stanford.edu/courses/420/) and the professor is an old school unix guy. He still lives in emacs. That being said I am totally open to various different languages / environments to do symbolic mathematics. I don't have a background in mathematics, so I feel my time might be better spent learning higher level concepts then trudging in the algebra trenches
Well this was also after a year of working on a fork in seclusion. The project by then had diverged quite a bit, and had quite a differing philosophy from the original.
