2004 seems really late for the inception (or possibly formalisation)
of Domain Specific Language, I assume that you're talking specifically
about embedded (also called internal) DSLs, otherwise SQL at least is
from 1986.
As an earlier example of an Embedded DSL, the book PAIP[1] included
prolog embedded in common lisp in 1992.
It could be argued that the loop macro in Common Lisp is a DSL for
describing iteration. If not loop, then certainly regular expressions
are a common EDSL for describing a regular language, and performing
operations with those languages against strings?
I found this snippet from Computers in Crisis [2] which
seems to describe domain-specific languages in familiar terms from
1975
Most domain-specific programming languages can be categorized in one
of two ways; either as a "sugared" general ... of programming, in
fact the style of problem solving, embedded in and supported by that
language remains unchanged.
It seems like for reduced calorie Coke specifically, it is marketed as "Diet Coke" or "Diet Coca Cola", in at least Australia[1], New Zealand[2], The United Kingdom[3], India, Israel and The US[4].
I think you've excluded the middle here, (#1.5 perhaps) one who thinks that your code is worthless/dangerous and does not call you a loser.
It can be true that a piece of software is a poor replacement for an existing tool.
It can be true that recommending it as a replacement for that tool is dangerous.
You can make these judgements about a piece of software without an incident like this happening. What's important here, is how you behave once you've made these judgements.
> It can be true that recommending it as a replacement for that tool is dangerous.
Unless you're suggesting that NASA rewrite its rocket guidance subroutines in a brand-new interpreted language or something, it's probably not unequivocally "dangerous." (In that case, I would call the suggester a different word than "loser".) That's the whole point of open-source software: everyone can make their own judgments about what works better for them.
In the specific case of `replace`, if I want to know exactly what the command-line options do, exactly what order the files are being modified in, I can glance over 173 lines of javascript rather than search through the 4.3MB (uncompressed) of the sed source code. Sure, I suppose I'd have to include the Node.js source code to make it a fair comparison, but my point remains: choose the solution that makes the most sense to you.
_But_ it is all about how it is written. Criticism is good when it is constructive, otherwise it is not far from just name calling, badgering and spewing of hate.
Other ways to respond could be "That's a cool idea. I like to use sed" or "checkout my python one-liner".
All those things you highlighted could be true, but that's still not a reason to offend someone.
It depends on who the author is:
* If an 8 year old wrote that, that would awesome and she would become an overnight internet celebrity.
* A Linus Torvalds wrote that -- everyone would become very worried that he is smoking something.
* Someone who is just learning to program -- it is awesome and they should be encouraged to do more of it
* A seasoned programmer -- they should still be encouraged but criticism should be more pronounced "Cool but sed usually works better, were you thinking of some specific feature?".
Yeah I mean it's OK to make judgements and think or believe whatever you want. Maybe even tell how a friend or two how silly something seems to you while hanging out. It's a different thing to being a dick to someone publicly on the internet for trying to contribute positively to open-source.
I don't think a critique of the code in question is especially relevant to the main point of the article, i.e. the practice of mocking open-source projects.
Debating the technical merits of this particular project can't really address that.
If you're after a standard library for Javascript, you could do worse than including es5-shim. Which has the advantage of being a library that (partially) implements a standard: Ecmascript 5.
> es5-shim.js and es5-shim.min.js monkey-patch a
> JavaScript context to contain all EcmaScript 5
> methods that can be faithfully emulated with a
> legacy JavaScript engine.
It provides Array::map, Array::filter, Array::reduce as defined in Ecmascript 5 along with String::trim and others, as well as replacing buggy implementations.
Previous versions of es5-shim included shims for things that cannot be correctly or completely shimmed in ES3 but those have since been separated and I now recommend including es5-shim in basically all web projects to get closer to a modern javascript in most browsers.
Sure. You could do worse than RubyJS as well. This project is implementing the standard set by the reference implementation of Ruby and its standard library. And having used Ruby a bit, I’ve come to find its standard library quite good, as dynamic languages go. So it doesn’t much matter that ES5 features are “more native”—here and now, it’s still a matter of preference.
I don't really see why RubyJS would be better than PHP.js.
And I'm definitely not saying that PHP.js should be used.
[edit] To be more specific, I really don't see the point of using a third-party library when the native methods are available. IMHO, if you choose a language, you should stick with it.
RubyJS creator here. I was just missing so many (native) methods in javascript. i liked the standard library of javascript and there is an extensive public ruby testsuite that i could use to test my implementation against. Plus i liked the idea of taking something that already works elsewhere and translate it JS, instead of coming up with my own API. IMO it's the same as using underscore/lodash, stringjs, etc, just all in the same library with the same coding standards and interoperability between classes.
Clearly jQuery isn't providing a lot of the things they are looking for in a standard library, as it is focussed on DOM manipulation and Ruby.js attempts to provide core types like Enumerables and Time.
No, Javascript is not "just scheme" with a few bad design decisions. They have significant differences.
Scheme has:
call-with-current-continuation http://people.csail.mit.edu/jaffer/r4rs_8.html#IDX509
Tail Call Optimisation
A numeric tower http://people.csail.mit.edu/jaffer/r4rs_8.html#SEC50
A Code/Data equivalence and therefore macros
Ports
Javascript has:
Prototypal inheritance
Every 'object' is mutable bag of string indexed properties
There's a pile of differences, even just at the semantic level before you get into the syntax or the equivalence semantics.
I understand that if you take a specific subset of javascript, you can write code as-though it has some scheme semantics (minus call/cc and TCO), but that's true to a similar extent of any language with lexical scope, closures and anonymous functions.
