Live data from Hacker News

The Next Big Language

steve-yegge.blogspot.com

61–70 of 75 posts

Re: The Next Big Language

#61
post #20

Earlier quoted context omitted.

How was that a great guess? Certainly things could change, but very very very few people are doing server side JS right now. That could change, but I'm still pretty skeptical. Node.js (if that's what you're thinking of) is still very much in the experimental stage.

Incidentally, i actually am doing server side javascript, but on Rhino, instead of node. I'm certain that Stevey meant Rhino, rather than node when he wrote that particular blog post.

he definitely meant Rhino, as in Rhino on Rails http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

Re: The Next Big Language

#62

I am really hesitating to mention this but maybe the discussion could help find a solution. The submitter clearly pasted the correct URL and got a link to the original submission (1311 days ago) but went ahead and added "?" to the end of the url to fool the dup filter and submitted again. It is not even a case of two different urls to the same dynamically generated page! I don't want to rush to accusation of karma wh…

I see no problem with this, the original submission is 3.5 years old. That's quite a long time to be complaining of reposts.

Yes I can see the value of reposting older submission, I think my main discomfort is having to add random characters to the urls in order to fool the dup detector so that people can post an old article again.

If the community agrees there is value in reposting old articles, maybe change the dupe detector to allow reposting old articles after N days. Since that would become part of the system (instead of working around it), it would become easier to link old and new submissions for example...

I just don't like it when one has to work against the system to do something if the community seems to feel that something is worth doing.

Re: The Next Big Language

#63

I am really hesitating to mention this but maybe the discussion could help find a solution. The submitter clearly pasted the correct URL and got a link to the original submission (1311 days ago) but went ahead and added "?" to the end of the url to fool the dup filter and submitted again. It is not even a case of two different urls to the same dynamically generated page! I don't want to rush to accusation of karma wh…

Last time I checked, the de-dup filter only looks at article that are less than x days old. (Not sure what the specific "x" is.)

Oh good idea! (see my other reply), unfortunately 3.5 years seems to still be disallowed, that's why the submitter had to add '?' to the url.

Re: The Next Big Language

#64
post #60
post #2

Ahh... I think we all miss Big Stevey. He role was never replaced and it's a shame for our entire community. I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline…

JS doesn't have optional static type-checking, does it?

I think Actionscript does, and back when this was written, it looked like Javascript was also going to - https://developer.mozilla.org/presentations/xtech2006/javasc... The standards people have since pulled back from the more radical designs (i.e, instead of going with Javascript 4, aiming for Javascript "Harmony").

Re: The Next Big Language

#65

Earlier quoted context omitted.

I see no problem with this, the original submission is 3.5 years old. That's quite a long time to be complaining of reposts.

Yes I can see the value of reposting older submission, I think my main discomfort is having to add random characters to the urls in order to fool the dup detector so that people can post an old article again. If the community agrees there is value in reposting old articles, maybe change the dupe detector to allow reposting old articles after N days. Since that would become part of the system (instead of working aroun…

Ah, I see what you mean. It is rather inelegant, but not that big of a deal, in my opinion...

Re: The Next Big Language

#66
post #59
post #35

Earlier quoted context omitted.

Nobody talked about F# here but it's clearly the CLR Next Language, and reasonably f&(*ing awesome; i.e. combines the Next Languageness of clojure, jruby, and scala from the JVM world. Invitably, people will raise the same "broad and deep syntax" complaints they level against scala

Clojure much bigger then Scala and F#. http://www.indeed.com/jobtrends?q=F%23%2Cclojure%2Cscala&#38...

For sure clojure's a nice language with a lot of great lib creators , and the community will continue to grow strongly

The (+), (+'), "=" and "==" thing has started to bother peeps

http://groups.google.com/group/clojure/browse_frm/thread/59a...

http://groups.google.com/group/clojure/browse_frm/thread/506...

http://clojure-log.n01se.net/date/2011-01-25.html#09:58a

Re: The Next Big Language

#67
post #59
post #35

Earlier quoted context omitted.

Nobody talked about F# here but it's clearly the CLR Next Language, and reasonably f&(*ing awesome; i.e. combines the Next Languageness of clojure, jruby, and scala from the JVM world. Invitably, people will raise the same "broad and deep syntax" complaints they level against scala

Clojure much bigger then Scala and F#. http://www.indeed.com/jobtrends?q=F%23%2Cclojure%2Cscala&#38...

Holy shit,according to your chart it is even bigger than C and Java! How did this happen without anybody noticing?

http://www.indeed.com/jobtrends?q=F%23,clojure,scala,+C,+Jav...

But maybe this is just a result of comparing relative growth rates of job postings. If you take the time to a look at the percentage of matching job positions, then Scala is pretty dominant (compared to Clojure and F#) :D

Re: The Next Big Language

#68
post #2

Ahh... I think we all miss Big Stevey. He role was never replaced and it's a shame for our entire community. I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline…

He was off on one item for sure: good tools for Javascript OUTSIDE web development.

I am currently in the middle of a 100k(not all mine) LOC embbeded Javascript project consisting of multiple files and it is rough going.

Eclipse IDE for JavaScript Web Developers is the crutch I am currently using, it feels better than most commercial packages I tried(Aptana, Komodo, etc.), but that is not saying much.

What I want most is the ability to reliably zoom in and out of functions, but the indexing over multiple files is quite shoddy.

The bad habits Javascript encourages make for frustrating reading of code (like where did that foo.bar just come from, if bar was not a property in the initial declaration of foo). Not everybody reads Crockford...

Until Javascript is feasible on larger projects, it will not be general purpose NBL.

Re: The Next Big Language

#69

I keep thinking that the Next Big Language will be a thing of re -evolution, e.g. someone going back to C and retracing steps of C++ but in a more sensible way. Also, on a tangential note -- the garbage collection is a huge deal if an adoption of the NBL among C/++ programmers is considered. The only way is to have the garbage collection optional. Similarly to how D has it, but much much simpler. Something like addin…

The D gc is not more a problem than C++ new is for real-time... RAII is possible and you can avoid allocations, also make custom allocators.

Re: The Next Big Language

#70

Earlier quoted context omitted.

just curious, do you allow malloc_gc'ed items to reference malloc'd ones?

Sure. malloc'ed item could be the same as malloc_gc'd, but with its reference count artificially bumped up by 1. free() would decrement the count and the item will be picked up by the GC later on. If there's a provision for an immediate disposal of unreferenced items, then we are back to the standard malloc/free behaviour in case when malloc and malloc_gc items are not mixed.

Reference counting is a bad C++ substitute for a real GC.
Post reply on HN