My anecdotal experience - not so much about the language itself but the ecosystem:
I was making a short evaluation of platforms for light 2d game/graphic development/prototyping. This being in the context of a fun project with very limited time - having kids and a C++/embedded day job and no intent to analyze core dumps in my spare time.
Haxe was on that list (together with e.g. lua/LÖVE and phaser.io/typescript) and I had high hopes for it. The number of target platforms would make it very attractive to transition from prototype to "publishable" game.
But what turned me down was the documentation and confusing state of competing libraries and target platforms.
E.g samples of a recommended tutorial were not working due to library changes (in very basic initialization functions). I found a solution but there was just too much friction .
So in the end, haxe lost in my evaluation because ... too much choice? I really wanted to have a predefined simple platform and just focus on gameplay.
If somebody has a recommendation for a haxe "starter kit" (compile target, libraries, docs, debugger/IDE/vim plugins ...) that allows to publish to all of desktop / html5 / mobile app then I'd be happy to hear about it. Maybe the next project...
Some of these languages (ponyc) are still...prototypes. Yeah you can get them working for a limited set of "working" and with very specific setup->configurations. If every language included a Docker or VM with it already set up for some level of demo, I think a rate for adoption/learning them would uptick.
> If every language included a Docker or VM with it already set up for some level of demo, I think a rate for adoption/learning them would uptick.
Programming languages are for programmers - the kind of people that run programmer-friendly OSs/distros and figure out how to make their own packages when needed.
You don't need containers and virtual machines when you can simply "emerge dev-lang/pony" and be on your merry way.
Anyway, Pony is not the right example for the point you're trying to make because it already provides Gentoo, Arch, Debian, RedHat, macOS and Windows packages plus a Docker image.
Interesting to note that Julia comes in at #9 on the list, ahead of Scala, Clojure, and Erlang. I still think it's the most underrated programming language of the decade and hope that its usage continues to grow. I know it's touted as a language for numerical computing and scientific research, but I believe it would make a great general purpose language, perhaps even better than Python.
Other than a few minor nitpicks, Julia is genuinely a joy to program in, and the depth of its feature goes very far (multiple dispatch, homoiconicity, genuine macros, sophisticated type system, runtime compilation via LLVM, clean interfacing with C code). I can't say the same for other languages. You can tell the language was designed and not cobbled together in an ad hoc fashion.
Does it still not have a decent charting library in the stdlib? I look at it every now and then (always looking for a good successor language for Python) and last I recall you had to use MatPlotLib? Is that accurate? This is stupidly simple in Matlab and should be here as well.
That would be a nope. Gadfly doesn't meet my needs and seems to have stalled in development, so I use Matplotlib via PyPlot, but Matplotlib is a bit maddening to work with. I heavily considered attempting my own plotting library during grad school but couldn't find the time for it :/
(Although I will say that Convex.jl makes up for all the pain of not having a good plotting library...)
Thanks for the reply. I agree that Matplotlib is too complex. I'd abandon Python today if Julia had simple charting in stdlib, but practically nothing does outside .NET (sadly, I'm not a fan).
It's worth noting that convex.jl is developed by the same folks as cvx (matlab) and cvxpy (python). They all provide access to the same solvers with similar abstraction and usability.
I'm not sure number of stars on gihub is a good measure of popularity of a language, especially when we're talking about number around 10k. I'm pretty sure Rust has more than 20K users, and Ruby and PHP have both more that 10K. Vast majority of these users though don't look through the C code of their engine and don't star it on github.
Participate in an Interview on Experience with Different Git Tools
My name is Angela and I do researches on user experience for different Git tools on the market. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more.
If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs. I’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.
If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!
Which of these projects has a truly open development process that takes place in public and on Github?
Are most (or some) of these developed internally by whichever enterprise is behind the language where developers at those companies "bake" commits and then push them up after going through an internal code review process?
Rust is one that's developed in the open. Commits to Rust's master branch must be done through pull requests on Github. All PRs must be approved and reviewed before being merged, and the approver cannot be the same person who submitted the PR. Furthermore, major changes to the language must undergo an RFC process, which is also coordinated via a Github repo: https://github.com/rust-lang/rfcs/ .
>Commits to Rust's master branch must be done through pull requests on Github. All PRs must be approved and reviewed before being merged, and the approver cannot be the same person who submitted the PR.
Any company that puts half an effort into open washing will follow these same procedures, so they aren't safe indicators that the real decisions aren't made behind closed doors ahead of time.
Paying close attention to things like the rfc process and approval process for commit rights and whatnot usually tell the real story.
clojure is close, but not done on Github. All work must be through jira/bitbucket but anyone can sign up for free with the only requirement is of a CA.
D is developed on GitHub and is open. Albeit there is no enterprise funding the development, it's small community is pushing the language forward. PR are reviewed and merged. But honestly sad to see it at the bottom of the list.
Scala (https://github.com/scala/scala) is completely developed on GitHub with Pull Requests requiring reviews being the only way commits can enter master. Issues are in a separate JIRA instance, although there is currently some experiments about migrating that to GitHub as well. A lot of other processes about the language, such as discussions about language features and their design, also are open on GitHub.
Its little brother Scala.js is entirely developed on GitHub too, complete with language proposals and issue tracking. https://github.com/scala-js/scala-js
The three Microsoft ones (C#, VB.NET, TypeScript – PowerShell is curiously missing from the list, though) are openly developed as well. I'm not sure there are many popular open-source languages these days where the developers work behind closed doors and only throw code dumps out every now and then.
Intended use?
A safe PHP and a safe container for remote execution of code.
Leaving your computer used by customers arbitrarily within bounded predictable resources making you less stressed and able to do capacity planning.
Lol. I am playing out of my league I hadn't spent much time on it and havent much perspective for valuing it :)
Much more a POC. But if I found a sponsor, I can finish it in 1 month :)
I still need to document the syntax of the FORTH I made, and create storage (~ vars and functions). But after that, my roadmap is handling the concept of integrity/units that will prove more efficient than typing.
Ex : if c is $/unit then comparing/adding it with something in €/l will abort.
Wow Go has really gained traction. Coming from a Python, PHP, JavaScript background I have been contemplating learning Go or Elixir this year. I am drawn to Elixir because of the functional approach which is different than what I am used to.
I've been learning both this year. Go at work and Elixir in my spare time. Both have a lot of similarities and the differences largely boil down to some root design decisions.
They are both great languages. I find Elixir to be more applicable to most of the work that I do (web work), personally. Phoenix is so much more polished than any of the web options in Go, I'd tend to make it my default. Go is where I'd reach when I needed to performance tune a very specific piece of a system generally. Can be a bit tedious for high level things.
Is CoffeScript still used much? I used it a bit a few years back when I was more interested in webdev and I liked it a lot, but I haven't really heard anything about it for a while. The only CoffeScript code I've seen lately is when I looked into finding the cause of a bug in a package for Atom several months backend back; I don't think I know of anything besides the Atom ecosystem that uses it nowadays, although I might just not be aware of other projects using it.
I think that CoffeeScript may have been a victim of its own success, now that ES6 is here and seems to have included many of its best features (e.g. arrow functions). We can also consider CoffeeScript to be the one to prove that "compile-to-JS" languages could succeed, so in that sense it sparked the modern surge of such languages (and, obliquely, perhaps helped justify WASM as well).
It is definitely less popular than it was pre-ES6, but it is still used.
I personally use it at work every day, plus I notice there are quite a few libraries (both open source and closed source) that are obviously compiled from coffeescript.
There is also work being done on a new version, CoffeeScript6, which will compile to ES6 and future ES standards. Check out the discussion at https://github.com/coffeescript6/discuss
It remains very popular amongst Ruby/Rails users, presumably due to less switching overhead between Ruby and CoffeeScript vs JavaScript.
ES6 has provided a lot of the features that people were hoping for in JS, and CoffeeScript doesn't seem to be worth the effort transpiling from anymore. It used to be the game in town for "better" JS, but TypeScript seems to have taken that position firmly.
CoffeScript is endorsed by DHH and so it's more of a first class citizen than JavaScript in Rails. However it's not something you have to use. I never really liked using it and I easily managed to keep using JavaScript in all these years since Rails 3.1. I hope it's going to the deprecation bin soon but I believe that Basecamp is using it a lot. DHH won't have added it to Rails if that was not the case.
ES6 has killed much of CoffeeScript's momentum, because of parity on a lot of language features, but I still find those that don't work with JS everyday still prefer it due to cleaner syntax, and fewer surprises.
i would contest the fewer surprises point. it may be convenient when it's your main language and you deal with it every day, but for somebody that only touches it once in a while it is riddled with quirks and warts. one has to constantly keep mental model of both languages in his head when developing to be productive.
trivial example:
{ a: b
c: d }
guess what this transpiles to (hint: not an object)
this is about as far from least surprise principle as you can get.
Idea for gh: It will be a nice feature categories or even tags for repos. I would like to see a similar list for databases for example, or even relational database, blog engines, etc.
I'm surprised that Coffeescript is still actively developed. Either there are still lots of legacy code out there to work on or some people just really love the language.
My last full time job was coffeescript. I could take or leave most of it, but returning to C# for a hobby project has made me really miss the null soak ? operator.
I'm sure the craving will go away with a few more days of messing.
Hey that's awesome! Thank you. I normally shield my eyes from the fancy new C# things like PLINQ and others because my hobby projects tend to sit in the Unity3d ghetto. Really cool to know they adopted that though.
You can't practically bootstrap an interpreted language. That being said, I'd be intrigued to see PHP run using multiple nested interpreters from different language versions.
Depends on what you define as interpreter, as RPython, the language that PyPy uses, actually has a VirtualMachine, turning PyPy more into a bytecode interpreted language... Which some people argue isn't a straight interpreted language.
The wiki and the issues are also lacking from GitHub because they are on a Redmine server at https://bugs.ruby-lang.org/
GitHub was written in Ruby (and Rails) so the issue tracker already existed and they felt it wasn't worth migrating it. I can understand why they don't feel like hosting all of their knowledge base on an external server when their one works well and their main repository uses a different technology.
I don't understand why they're still on subversion. Maybe some custom build tools they don't want to migrate to git?
The core team indicated they quite like the sequential numbering that SVN gives them. I'm considering building it into GitLab as an option if they would use it to host ruby :)
Mercurial and bzr have those sequential numbers. They really aren't the awful apocalyptic problem that git users seem to think they are. bzr tries harder to make them sequential and meaningful, but even hg's more lax approach to revision numbers is still useful: they are still approximately semantic, much more than node hashes.
Inspired by Mercurial, we built such functionality for GIT backend in RhodeCode.
So the numeric identifiers are used now for all 3 backends we support. Kallithea has it also implemented for GIT.
I personally never like the meaningless hashes. Those numbers act as good identifier of project size and progress. It quickly shows what kind of ranges we're taking when doing a compare, or simply looking at files and seeing those numbers.
It gives a lot of context. Just look how much more useful information a compare shows
r1808:39334bf35fdf...r1819:3e8df3a82397
vs
39334bf35fdf...3e8df3a82397
I'd like to understand how it could work. For the simple case with a master branch and one feature branche we could number commits as they are merged into master. What about two branches worked on at the same time, with multiple commits and merged to master? If the numbering has to reflect the timestamps of the commits it should be recomputed at every merge which is probably not desirable. However every branch has its own numbering and I don't know if it's desirable to have two numbers for the same commit.
132 comments
[ 3.3 ms ] story [ 274 ms ] threadhttps://www.google.com/trends/explore?date=all&q=%2Fm%2F0dbj...
Granted, this was six years ago, so it's probably better now.
It can still be improved, but it's miles better than it was years ago.
My guess is that there are way too many moving pieces since Haxe needs many side projects to be the universal language it promises to be.
I was making a short evaluation of platforms for light 2d game/graphic development/prototyping. This being in the context of a fun project with very limited time - having kids and a C++/embedded day job and no intent to analyze core dumps in my spare time.
Haxe was on that list (together with e.g. lua/LÖVE and phaser.io/typescript) and I had high hopes for it. The number of target platforms would make it very attractive to transition from prototype to "publishable" game.
But what turned me down was the documentation and confusing state of competing libraries and target platforms.
E.g samples of a recommended tutorial were not working due to library changes (in very basic initialization functions). I found a solution but there was just too much friction .
So in the end, haxe lost in my evaluation because ... too much choice? I really wanted to have a predefined simple platform and just focus on gameplay.
If somebody has a recommendation for a haxe "starter kit" (compile target, libraries, docs, debugger/IDE/vim plugins ...) that allows to publish to all of desktop / html5 / mobile app then I'd be happy to hear about it. Maybe the next project...
[0] https://github.com/NixOS/nix [1] https://nixos.org/nix/manual/#ch-expression-language
As to the ease of compiling it... I've always compiled it from source, to track some bleeding-edge features, and compiling ponyc is a breeze.
Programming languages are for programmers - the kind of people that run programmer-friendly OSs/distros and figure out how to make their own packages when needed.
You don't need containers and virtual machines when you can simply "emerge dev-lang/pony" and be on your merry way.
Anyway, Pony is not the right example for the point you're trying to make because it already provides Gentoo, Arch, Debian, RedHat, macOS and Windows packages plus a Docker image.
[1]: http://golo-lang.org/
[2]: https://www.eclipse.org/community/eclipse_newsletter/2016/oc...
Other than a few minor nitpicks, Julia is genuinely a joy to program in, and the depth of its feature goes very far (multiple dispatch, homoiconicity, genuine macros, sophisticated type system, runtime compilation via LLVM, clean interfacing with C code). I can't say the same for other languages. You can tell the language was designed and not cobbled together in an ad hoc fashion.
That would be a nope. Gadfly doesn't meet my needs and seems to have stalled in development, so I use Matplotlib via PyPlot, but Matplotlib is a bit maddening to work with. I heavily considered attempting my own plotting library during grad school but couldn't find the time for it :/
(Although I will say that Convex.jl makes up for all the pain of not having a good plotting library...)
https://github.com/tbreloff/Plots.jl
I still prefer Gadfly, which does everything I need while looking great. (Only nitpick is slow time to first plot in each session.)
http://gadflyjl.org/stable/
My name is Angela and I do researches on user experience for different Git tools on the market. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more.
If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs. I’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.
If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!
Cheers, Angela Guo 378496625@qq.com
Are most (or some) of these developed internally by whichever enterprise is behind the language where developers at those companies "bake" commits and then push them up after going through an internal code review process?
Any company that puts half an effort into open washing will follow these same procedures, so they aren't safe indicators that the real decisions aren't made behind closed doors ahead of time.
Paying close attention to things like the rfc process and approval process for commit rights and whatnot usually tell the real story.
Everything we do is through GitHub issues and PRs.
Its little brother Scala.js is entirely developed on GitHub too, complete with language proposals and issue tracking. https://github.com/scala-js/scala-js
https://github.com/jul/confined
Intended use? A safe PHP and a safe container for remote execution of code.
Leaving your computer used by customers arbitrarily within bounded predictable resources making you less stressed and able to do capacity planning.
Lol. I am playing out of my league I hadn't spent much time on it and havent much perspective for valuing it :)
Much more a POC. But if I found a sponsor, I can finish it in 1 month :)
I still need to document the syntax of the FORTH I made, and create storage (~ vars and functions). But after that, my roadmap is handling the concept of integrity/units that will prove more efficient than typing.
Ex : if c is $/unit then comparing/adding it with something in €/l will abort.
See http://daurnimator.com/post/153864402074/githubcomlua for more info
https://github.com/leafo/moonscript
They are both great languages. I find Elixir to be more applicable to most of the work that I do (web work), personally. Phoenix is so much more polished than any of the web options in Go, I'd tend to make it my default. Go is where I'd reach when I needed to performance tune a very specific piece of a system generally. Can be a bit tedious for high level things.
I personally use it at work every day, plus I notice there are quite a few libraries (both open source and closed source) that are obviously compiled from coffeescript.
There is also work being done on a new version, CoffeeScript6, which will compile to ES6 and future ES standards. Check out the discussion at https://github.com/coffeescript6/discuss
ES6 has provided a lot of the features that people were hoping for in JS, and CoffeeScript doesn't seem to be worth the effort transpiling from anymore. It used to be the game in town for "better" JS, but TypeScript seems to have taken that position firmly.
trivial example:
guess what this transpiles to (hint: not an object)this is about as far from least surprise principle as you can get.
[0] http://coffeescript.org/#try:%7B%20%22a%22%3A%20%22b%22%2C%2...
http://coffeescript.org/#try:%7B%20a%3A%20b%2C%20c%3A%20d%20... - object
http://coffeescript.org/#try:%7B%20a%3A%20b%0A%20%20c%3A%20d... - bullshit
i understand why this happens, i just think it's a stupid edge case that shouldn't exist. and there are more like that in coffeescript.
But, I'd still take an edgecase over other JS quirkiness.
edit: big list of lists: https://github.com/sindresorhus/awesome
I'm sure the craving will go away with a few more days of messing.
https://github.com/nodejs/node
I wonder when we'll see Swift written in Swift. And I wonder what kind of monstrosity a PHP written in PHP would look like.
[0] https://en.wikipedia.org/wiki/Meta-circular_evaluator#Exampl...
It's actually a superset of a subset of Python and it's called RPython: http://rpython.readthedocs.io/en/latest/rpython.html
> it supposedly is faster than python's C implementation
Only if its JIT compiler gets a chance to trace and compile some code which is then executed often enough to make up for the overhead.
Anyone know why ?
https://github.com/trending?since=monthly
https://github.com/trending?since=weekly
The wiki and the issues are also lacking from GitHub because they are on a Redmine server at https://bugs.ruby-lang.org/
GitHub was written in Ruby (and Rails) so the issue tracker already existed and they felt it wasn't worth migrating it. I can understand why they don't feel like hosting all of their knowledge base on an external server when their one works well and their main repository uses a different technology.
I don't understand why they're still on subversion. Maybe some custom build tools they don't want to migrate to git?
I personally never like the meaningless hashes. Those numbers act as good identifier of project size and progress. It quickly shows what kind of ranges we're taking when doing a compare, or simply looking at files and seeing those numbers.
It gives a lot of context. Just look how much more useful information a compare shows r1808:39334bf35fdf...r1819:3e8df3a82397 vs 39334bf35fdf...3e8df3a82397
Would you implement it using tags?