Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Julia Programming Language

julialang.org

Post reply on HN
Print view View original

41–50 of 211 posts

Re: The Julia Programming Language

#41

Post by kib2 »

mjwalshe wrote: post #31
simonw wrote: post #24

Earlier quoted context omitted.

That's pretty common for new language implementations - Node.js was around for a couple of years before the Windows port was ready. To be honest, if you're targeting early adopters of a programming language Linux and Mac support is probably a lot more important than Windows. Smart Windows users can always run Linux in a VM.

and most users of this sort of languages aren't going to be running it on windows but on Unix systems.

Are you insinuating that Windows users are too stupid to use those languages (and use only rotten ones like V.B etc. ) ​​?

Please, be a minimum objective and constructive.

Re: The Julia Programming Language

#42

Post by bo1024 »

kib2 wrote: post #19

No Windows support, really ?!

Look at the goal applications: scientific computing, automatic multithreading/parallelism, distributed tasks across multiple machines.

That doesn't sound trivial to port to Windows, and I'm sure their own application was their first priority.

Re: The Julia Programming Language

#44

Post by maximilian »

ludwigvan wrote: post #29
wbhart wrote: post #28

Much praise!! These guys have incredibly good taste. Almost every single thing I can think of that I want in a programming language, they have it. All in the one language! The fact that it has parametric types, parametric polymorphism, macros, performance almost as good as C, good C/Fortran interop, 64 bit integers and an interactive REPL all in the one language just blows my mind. I wasn't able to tell if it is poss…

I think they are aiming for smooth transition for MATLAB users. They also have 1-index based arrays as opposed to 0-index .

Fortran is 1-index as well. I think MATLAB gets its notational style from Fortran.

Re: The Julia Programming Language

#45

Post by kghose »

So, the usual caveats about writing code to match the languages strengths apply here. For example the fib function plays to a python weakness - function overhead. Rewriting the code to be a simple loop removes the inefficiency:

  import time
  
  def fib(n):
    if n

Re: The Julia Programming Language

#46

Post by ajdecon »

kib2 wrote: post #41
mjwalshe wrote: post #31

Earlier quoted context omitted.

and most users of this sort of languages aren't going to be running it on windows but on Unix systems.

Are you insinuating that Windows users are too stupid to use those languages (and use only rotten ones like V.B etc. ) ​​? Please, be a minimum objective and constructive.

I doubt it was intended as an insult. Julia (and other scientific languages) are often used in clustered environments, and Linux is much, much more common than Windows in HPC.

Re: The Julia Programming Language

#47

Post by mkl »

The language looks interesting, but I am a bit concerned about the license situation, as in my understanding they have misinterpreted the GPL with regard to shared libraries. Quoting:

Various libraries used by the Julia environment include their own licenses such as the GPL, LGPL, and BSD (therefore the environment, which consists of the language, user interfaces, and libraries, is under the GPL). Core functionality is included in a shared library, so users can easily and legally combine Julia with their own C/Fortran code or proprietary third-party libraries.

The FSF disagrees (http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins):

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

Re: The Julia Programming Language

#48

Post by pron »

mjw wrote: post #26

I wonder what they think about or have learned from http://en.wikipedia.org/wiki/Fortress_(programming_language) , another recent-ish attempt to deliver a modern and powerful scientific programming language. Personally I'm a little wary of being ghettoised into something overly domain-specific for scientific/numerical computing. Really good interop may mitigate that -- something which can navigate the unholy mix of C…

I've been waiting for Fortress for a LONG time, but either progress has been real slow or the Fortress team has trouble communicating their progress to the community. Probably both.

From a quick look I can tell that while Fortress is more similar to Scala, with classes, mixins and static typing, Julia is closer to Clojure, with no encapsulation, dynamic typing, homoiconicity, and separation of behavior (methods) from concrete types (akin to Clojure's protocols).

I really like the choices Julia's designers have made, particularly multiple-dispatch methods, final concrete types and lispy macros. The language seems very elegant. Not too crazy about "begin" and "end" syntax, though :)

Re: The Julia Programming Language

#49

Post by _delirium »

mkl wrote: post #47

The language looks interesting, but I am a bit concerned about the license situation, as in my understanding they have misinterpreted the GPL with regard to shared libraries. Quoting: Various libraries used by the Julia environment include their own licenses such as the GPL, LGPL, and BSD (therefore the environment, which consists of the language, user interfaces, and libraries, is under the GPL). Core functionality…

I believe what they're saying is that there are two things:

1. The Julia core, which consists of the language runtime and core functionality, is MIT licensed, and builds into an MIT-licensed shared library.

2. The Julia "environment", which includes a user interface, third-party libraries, etc., some of which are GPL, and which is therefore GPL as a whole.

I believe they're saying that you can link #1 with proprietary code, not meaning to imply that you can link #2 with proprietary code (because as you point out that wouldn't work). How useful that is probably depends on how many of the libraries the average application needs are in bucket #1.

Re: The Julia Programming Language

#50

Post by drats »

apl wrote: post #23
drats wrote: post #22

Earlier quoted context omitted.

Well you are being a bit nitpicky as pypy is both the python implementation and the JIT/Rpython/framework bit. What I mean was someone holding very close to the python implementation in almost everything (syntax etc.) but streamlining it/breaking compatibility/giving it a new name ("python3-as-it-should-have-been" perhaps?). Further, if we are going to be nitpicky, when you use something like that for its intended pu…

> if we are going to be nitpicky, when you use something > like that for its intended purpose it's still a fork No. Fork is definitely not semantically congruent with use. You're only forking Bootstrap if you create a path that diverges from its mainline; don't get confused by GitHub parlance.

Pypy most commonly refers to the python implementation anyway, as can be easily seen by going to the pypy website[1]. Daslch abused the fact that "pypy" points to two things to make a meaningless nitpick. Now you are claiming that I have claimed that fork and use are semantically congruent, where do I claim that? I think you are nitpicking and parsing "it" wrong. In either case a question asking for clarification would be more polite than going on attack.

There seems to be a disease, let's call it Eric Raymond Disease (ERD), on HN in particular[2] of people busting in rudely to declare with supreme confidence on the usage of quite generic words and/or slang. Let's start by tabling the fact that a particular "software definition" of "fork" has not yet reached the OED, or online dictionaries like Merriam-Webster for that matter. Going from that I can't see how you can declare it to only have one definition when you already admit there is a competing one ("GitHub parlance"). The base concept of the word fork is a divergence, a branch, which seems to me to cover any copy+modify move for software so someone copy+modifying bootstrap is forking it, someone copy+modifying the implementation of python called pypy is forking it.

Are you and Daslch really contributing to HN or are you taking a rather banal comment and turned it into a 100% useless thread by bickering over semantics?

[1]http://pypy.org/ [2]http://news.ycombinator.com/item?id=3467035

Post reply on HN