Gosu Programming Language Released To Public 330
llamafirst writes "Guidewire Software released the Gosu programming language for public availability. Gosu is a general-purpose programming language built on top of the Java Virtual Machine (JVM). It is object-oriented, static typed, imperative, and 100% Java compatible (use/extend Java types, implement Java interfaces, compile to Java bytecode). It has type inference (very readable code yet static typing!), in-line functions that you can pass as objects (closures / lambda expressions / blocks), enhancements (inject methods + properties, even on Java types!), and simplified generics. Gosu is provided via the Apache License v2.0. The language itself is not yet open source, although that is planned for a future community release. You can read a complete introduction to the Gosu language, a comparison to other languages, and syntax differences from Java."
Sounds like Scala (Score:3, Insightful)
From a quick glance it looks like Scala with a more Java-like syntax... I wonder what added benefit they hope to bring.
I'd be very interested to see an in-depth comparison of the two.
Re:Sounds like Scala (Score:4, Informative)
OK, replying to myself because I obviously didn't have enough coffee yet:
They list as the benefits over Scala
- Extensible type system
- Easy transition from Java
- Reified Generics
From those 3 points, only the last one sounds useful...
Re: (Score:2)
I haven't read the docs yet, but how can they claim reified generics and full Java compatibility?
Re: (Score:2)
OK, replying to myself because I obviously didn't have enough coffee yet:
They list as the benefits over Scala - Extensible type system - Easy transition from Java - Reified Generics
From those 3 points, only the last one sounds useful...
Except that reified generics are available in Scala using manifests [scala-blogs.org]. I am not sure what the "extensible type system" means but there are various ways of adding to a type system in Scala. However I agree on not being an "Easy transition from Java". Scala is not really an easy transition from anything!
Re: (Score:2)
No, Scala doesn't have reified generics. You can get something like reified generics in Scala using manifest that covers some cases. In addition, Scala manifest are experimental, and not a stable part of the language and there is no schedule for when they will be (I still use them though.)
True, you have to implement reified generics yourself using manifest. I have not found any limitations myself yet, but I have to admit that I have only done simple reified type collections.
I disagree (Score:3, Insightful)
OK, replying to myself because I obviously didn't have enough coffee yet:
They list as the benefits over Scala - Extensible type system - Easy transition from Java - Reified Generics
From those 3 points, only the last one sounds useful...
You are kidding right? In reality-land, for better or worse, #2 is probably as important of all for a lot of Java shops as #3 if not more. Type erasure sucks balls, but we can get it to work (just as we were able to write good working code without generics.)
Adoption and ease of transition are things people tend to undervalue/underestimate. Being able to leverage a language with better qualities with as little code change as possible is certainly an enormous, practical incentive. For me, I would give an ey
Re: (Score:2)
Why do you need it in a Java-like?
Re: (Score:2)
Well if it were a superset of Java then the answer to that should be obvious. I sense people are getting seriously fed up with Oracle / Sun's glacial development schedule as well as all the legal shenanigans. Java 7 is the Duke Nuke Em of language iterations. If someone produces a Java with extensions (almost like C++ was C with classes originally) then they might jumpstart development a
Re: (Score:2)
Another Language (Score:4, Insightful)
Then one day I woke up and realized, it isn't the language, you can write good or bad code in any language. It's how you use the language, and how you organize the code that matters most. I realized as long as you have the ability to encapsulate, you can write good code in any language, even in assembly.
In fact, with a good macro library, I can write code just as fast and well in assembly as in any other language.
Or, on the other hand, maybe I've fallen into the trap represented by this saying, "The determined real programmer can write Fortran in any language." But I don't think so.
Re: (Score:2)
As long as you're not writing GW-Basic or COBOL in any language, I think you're not too far gone.
Re:Another Language (Score:5, Insightful)
Perhaps it is tempting to see only encapsulation as the sine qua non in programming languages. However, a programming language does not merely make an algorithm machine readable, but also human readable (eg. yourself after 2 weeks). Therefor, the following properties are important:
- Conciseness: eg. Haskell is more suitable in representing certain algorithms, as part of the interpretter/compiler makes 'good' choices, you'd have to specify otherwise. The same goes for languages such as Prolog.
- Manipulatibility: to change a certain aspect of an algorithm (or of a whole system), we need a representation of this aspect. Aspect Oriented Programming, Lambda expressions and meta-object oriented programming are examples of this.
- Suitability to domain: whether a mathematician or a business process manager reads your code matters. Their experience and expectations differ.
- lots more...
Yes, all of it is reducable to a Turing Machine, but languages matter. A lot.
Re: (Score:3, Insightful)
My point is, if you give me sufficient encapsulation tools, I can write code that is concise, readable and manipulable. And it is something anyone can do.
Re:Another Language (Score:4, Insightful)
But, VB makes writing bad code trivial, and writing good code challenging.
Re: (Score:2)
it isn't the language, you can write good or bad code in any language But, VB makes writing bad code trivial, and writing good code challenging.
COBOL even more so
Re:Another Language (Score:5, Insightful)
Exactly. Which is why this "all languages are equivalent" mantra is just so much bullshit. All languages have domains for which they are more or less suited.
I don't do script-like tasks in assembler, I don't do device drivers in Java, I don't write enterprise apps in Javascript or VB. Neither do most sane software engineers. This isn't a coincidence, it's because certain tools are better at certain jobs. People who argue that it doesn't matter what language you use cannot explain why good software engineers know why some languages are inappropriate for some jobs.
Re: (Score:3, Insightful)
Hey, I'm gonna try for an analogy that is neither cars nor pizzas. Let the mod points roll !
Languages are like MP3 players: some have strong points, extra features, nice ergonomics better price.. but in the end, what counts is the Apple-like ecosystems: users, developpers, tools, PR, content...
Judging a language on its own merits is nice and all, but in the end, wuality of the tool sets, docs, hype... are probably a bigger contributing factor.
Re: (Score:2)
Re: (Score:3, Insightful)
Learning languages and their philosophies... (Score:5, Insightful)
It's good to learn some assembly languages to see how machines work.
It's good to learn C to get accustomed with low level things, pointer arithmetic, in-memory layout of code & data, OS internals and tons of other things. It's good to tinker and experiment with high performance C code, see how functions look disassembled. Try adding two matrixes row by row and then column by column and see performance differences etc.
It's good to learn C++ to get accustomed with it's metaprogramming facilities, learn how to implement semi-automatic memory management via smart pointers and how all these high level things interact with low level.
It's good to learn Java to get accustomed with that whole big world of objects, OOP patterns, TDD, exception handling strategies and tons of other things.
It's good to learn Scala to get smooth introduction into functional programming concepts (higher level functions, closures etc.) and see how it can be incorporated into traditional object oriented code and more interesting concurrency models (actor model for example).
It's good to learn Erlang to grasp functional programming even more, learn how to effectively use pattern matching, see the THE actor model implementation and learn about it's interesting error handling philosophy.
It's good to learn LISP to grasp it's macro system that still cannot be matched in any other language. See Common Lisp at work and Clojure for it's approach to parallelism, mutability and distinction between values and identities.
It's good to learn Haskell to see how to program in purely functional way and see monads in action.
Not that I'm in any way competent in all things above. Much of it (plus other things) is still on my TODO list. I'm still being surprised by new ideas showing blind spots of my ignorance on regular basis. I don't buy however that learning new languages doesn't matter anymore. It matters. It's important. Maybe we should choose new languages to learn more carefully, choose less but dig deeper.
Re:Another Language (Score:4, Insightful)
How many lines do you need to emulate a Python's list comprehension statement in assembly? Even if you encapsulate, assembly simply doesn't let you express everything in the statement without a massive number of LOCs.
Higher level languages are more readable for higher level concepts. It's not the same.
Re: (Score:2)
But then again I think of it as a bit like wine-tasting. Tasting as many langauges as possible gives me the ability to identify what goes best with what, how do I know if a task is more suited to Perl than assembler - only because I have used both. That said there has to be limits, if I have been using Java exclusively for a few months, it may be a lot quicker for me do some data mangling in Java even though it may require 10x as many lines of code the equivalent Perl (simply because I'll have to switch my
Re: (Score:2)
You can write good code in any language but can (a) other people and (b) the compiler understand what you meant?
It's assembly, you don't need a compiler. :)
With comments and well-named labels and macros, assembly isn't too hard for a human to understand.
Re: (Score:2)
mov ax, 4c01
int 21h
Re: (Score:3, Insightful)
A compiler translates code INTO assembly (or machine code). An assembler translates assembly code into machine code.
Geez, the kids these days are spoiled with their fancy IDEs, and don't even know what assemblers and linkers are. So sad.
Re: (Score:2)
"there's no way any normal person can write easily in C what is possible in Haskell."
Oh rubbish. Do you think haskell is magic or perhaps it uses special CPU opcodes no other language knows about? Languages like Haskell just make certain concepts and constructs quicker to write, not possible to write. And since a lot of haskell interpreters are written in C ergo whatever you can do in Haskell you can do in C.
Re: (Score:2)
http://en.wikipedia.org/wiki/Turing_tarpit [wikipedia.org]
Don't be ridiculous. "All Turing complete languages are Turing complete" is not an argument, its a tautology. ... anything. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.6.7628&rep=rep1&type=pdf [psu.edu]
The question is how easily a concept can be expressed and reasoned about. By your logic, because diophantine equations can encode a lisp interpreter, they are a reasonable way to implement
Re: (Score:3, Interesting)
there's no way any normal person can write easily in C what is possible in Haskell.
I used to think that too, up until about a week ago when someone on reddit was challenged [reddit.com] to write a C++ equivalent to Haskell's zippers. What he came up with was pretty impressive.
Possibly that guy is not a normal person though. :)
Run for the hills! (Score:2)
Its new age cobol. I can hear the PHB now. If we use and instead of && our secretary will understand how to code and we'll save milions!
Re: (Score:2)
If we use and instead of && our secretary will understand how to code and we'll save milions!
Watch out for when your secretary learns to fly, then - for she's coding in Python and she's gonna import antigravity!
Re: (Score:2)
If we use and instead of && our secretary will understand how to code and we'll save milions!
Watch out for when your secretary learns to fly, then - for she's coding in Python and she's gonna import antigravity!
Well I hope she remembers to indent correctly.
Re:Run for the hills! (Score:4, Funny)
As a geek, you should actually prefer "and", because it is quicker to type than "&&" - it does not engage Shift, and it does not require pressing the same key twice (which requires waiting for release after the first press). Same for "or" vs "||".
Re: (Score:3, Funny)
var1&&var2 works but var1andvar2 doesn't
Re: (Score:2)
var1&&var2 works but var1andvar2 doesn't
Well yes, you can write it all on one line as well. But if you really want to go that way, nothing beats APL.
Re: (Score:2)
Try using spaces
Re:Run for the hills! (Score:4, Insightful)
Re: (Score:3, Interesting)
No, as I geek I prefer because "readability counts". Gains in productivity from key presses are irrelevant compared to the gains in productivity from understanding code as you skim it.
Re: (Score:2)
Very neat (Score:2)
Yuck!!! (Score:2, Interesting)
Phonetically gosu sounds identical to the Portuguese word "gozo", which literally means cum (as in ejaculation).
Re: (Score:2)
Only in Brazil. It has no such connotation in Portugal.
Re: (Score:2, Interesting)
Interesting to know. Originally it was used in the same way as it is used in Spanish, meaning joy or pleasure (when a noun). In Brazilian Portuguese it has acquired the sexual connotation besides the usual meanings. Funny thing is that I just discovered that gozo means sweet in Basque.
Epic type system fail - universal covariance (Score:5, Informative)
The introduction has this gem:
Gosu supports a simplified version of generics. Generics are a way to abstract the behavior of a class to work with different types of objects, but to still retain type safety. There are no wildcards, and generic types are covariant, like Java arrays, which is usually what you want.
And here's how to make the type system bite the dust with this flaw:
What's funny is that Eiffel has already fallen into the very same trap [loria.fr], and is still trying to dig itself out of it [eiffel.com].
Re: (Score:2)
The really funny thing is that in practice all generics really need to do is prevent you from having to repeat casts everywhere, catch errors moderately soon, and aid in documentation. Which is what these do. The real 'trap' here is thinking that something has to be theoretically perfect to be useful or convenient.
Re:Epic type system fail - universal covariance (Score:5, Insightful)
The really funny thing is that in practice all generics really need to do is prevent you from having to repeat casts everywhere, catch errors moderately soon, and aid in documentation. Which is what these do.
They don't let you "catch errors moderately soon" in many real scenarios. It's the same problem as implicit null value for reference types everywhere - end result is you can have one part of code returning null where it shouldn't, that null get quietly propagated throughout your system from component to component because no-one needs to do anything to it, and then it all finally blows up when some other code elsewhere receives a value that should not be null but is - and you end up with a NullPointerException and, often, no clue as to what code originally produced the invalid value.
Same thing here - someone, somewhere will create a collection of subtype, implicitly upcast it to supertype, and pass it over because they do not understand that List<Number> cannot always be substituted for any random List<Object> - because it's non-intuitive, despite being true (since add() is not covariant). All the evidence I need for this are all the questions asking about how to do just that in Java or C# on StackOverflow. When you ask people to post the code, it almost invariably turns out to be broken, and the type system did them a favor by rejecting it.
The real 'trap' here is thinking that something has to be theoretically perfect to be useful or convenient.
We're not talking about "theoretically perfect" here. We're talking about a language that's statically typed - the sole benefit of which is type safety unless explicitly overriden (by casts etc) - but which then forgoes this very benefit.
Furthermore, the only other language I'm aware of which has the same flaw is Eiffel. Neither Java nor C# nor any other language with generics has this. They all either have no variance at all (which is inconvenient by safe), or declaration-site variance (C# 4.0 "in" and "out" on type parameters) which is easier on the API client but does not let you express all relationships, or usage-site variance (Java generic wildcards) which requires API client to understand what it is all about.
Re: (Score:2)
Re: (Score:2)
* @param {?string} input string that may be null
* @return {!string}
**/
function makeDefaultIfNull(input) {
return (input) ? input : "Default";
}
Re: (Score:2)
Talking about initial null references and all, I don't know about your Java compiler, but mine refuses to compile a program where an initially unassigned reference is attempted to be used. That's what it's all about isn't it - if the initial use of a unassigned (null) reference is prohibited at compile-time, then surely nothing will propagate anywhere and make a mess? Please advise ;-)
Additionally, and regardless of how smart/strict a compiler is, are you saying that you would prefer another constant such a
Re: (Score:3, Informative)
Talking about initial null references and all, I don't know about your Java compiler, but mine refuses to compile a program where an initially unassigned reference is attempted to be used. That's what it's all about isn't it - if the initial use of a unassigned (null) reference is prohibited at compile-time, then surely nothing will propagate anywhere and make a mess?
No, that's not it. The initial value of an unassigned local variable is "unassigned", not null, which is why the compiler won't let you use it unless all code paths leading to the current point assign or initialize it. But you can still explicitly initialize with null, and then everything I said applies.
Unassigned fields are initialized to null, and can be used as such with no explicit assignment/initialization.
Additionally, and regardless of how smart/strict a compiler is, are you saying that you would prefer another constant such as say 'unassigned' (which in fact cannot be assigned explicitly) as a value for unassigned references? Then, if an 'unassigned' value pops up from nowhere at runtime after your program has aborted with a thrown exception, you at least know that it was not a null pointer but that you're using a compiler that cannot tell where an unassigned reference is being used? Just thinking aloud...
No. The point is that the type system should ensure that a reference that is possibly null cannot
Re: (Score:3, Interesting)
Fair enough. I still hold by my earlier assertion that this is the mistake of the same proportion and impact as nullable-types-by-default (about which there have been repeated published regrets by the very language designers which introduced them), but I do understand the argument from pragmaticism. Time will tell if your trade-off was worth it or not.
Then again, those who grok variance (and other advanced stuff) already have Scala, while Gosu could take the niche of a language that is not that far removed
Re: (Score:3, Informative)
Which makes me wonder, what do all these language-design people have against contravariance?
It depends on which of the two we're talking about: variance of method argument and return types, or variance of generics.
For generics, the logic goes roughly like this:
1. Generics are mostly used for collections.
2. Intuitively, people expect a collection of objects of derived class to be substitutable for a collecton of objects of base class, even if it is not sound.
3. In practice, most uses of collections per #2 are sound (i.e. only use the covariant methods, not contravariant ones).
4. So, just default to
Re: (Score:2)
Their main 'competitor' Scala (in my mind) has both covariant and contravariant type system.
So in the language comparison, they left out covariant and contravariant..
*Sigh*
Re: (Score:3, Insightful)
Since when does the line xs=ys; not generate a warning
Are you, perhaps, confusing it with Java arrays? This is Gosu, not Java. It does not generate any warnings there, by design. In Java, the direct translation of the above would have not compiled. It would have compiled if those were arrays and not Lists, and would have not generated a warning in that case.
call be back.... (Score:5, Insightful)
>> The language itself is not yet open source,
ok, call me back once it is. I don't really need another programming language, let alone a closed-source once.
Gosu is an unrefined mix (Score:2)
Gosu is an unrefined mix of cobalt oxide, sodium and other minerals mined in China.
Yup, so very right.
YASBTJ (Score:2)
Re: (Score:2)
Unless Sun/Oracle finally gets its act together and implements some language improvements, we will see another bunch of those languages. Properties have been requested for ages, closures have been discussed for how long. Dynamic reloading of classes for real hotswapping still is a pain in the arse. Java has done so many things right, but like many other sun technologies it falls short by 5% and then it takes ages to get it in out of the fear of breaking compatibility. I personally wonder if it would not be
Re: (Score:2)
Properties have been requested for ages, closures have been discussed for how long.
AFAIK properties are not on the radar, but lambdas are coming in Java 8. You can track the work (both design and implementation - there's already code to try out) here. [java.net]
To me the Dalvik VM from a modern standpoint makes more sense on bytecode level than the registere based JVM.
It's Dalvik which is register-based (which makes fast interpreters easier to implement). JVM is stack-based.
Online help browser sucks. (Score:4, Insightful)
Gosu people, your help browser sucks caravans.
If I middle-click on a link, I don't want the page I'm currently reading to jump away. I want to read whatever is linked to _later_. Redirecting me and then breaking my browser's "Back" button, without even providing an alternative js back button, is unforgivable.
It is case-insensitive... (Score:2)
Re: (Score:2)
0RLY? N4h, wh47 w3 w4n7 15 N07 c453 1n53n5171v3, 8u7 4 1337 c4p4813 14n6u463...
Programmers are excused from learning proper English language capitalization, punctuation and spelling (and other written language semantics (like proper "quote usage", and avoiding nested paren
Cool. Next, fix the VM (Score:2)
Re: (Score:2)
The problem with generics are not on vm level, it is more the problematic implementation on javas side. The JVM after all is just assembler with high level constructs for classes and data types to some degree, it can scale to any generic implementation you can think of.
Wow... (Score:2)
Not real (Score:2)
Not real until you post its operational semantics!
Looks very interesting (Score:2)
But I really like my semicolons (as much as lispers like their parenthesis)
Interesting (Score:2)
After all, a programming language syntax does not need to be "encrypted" to be effective.
Scalars weakly typed? (Score:2)
A quick look at the documentation shows that objects/classes are strongly typed, but scalars (i.e. integers) apparently are not. In my experience, you're much less likely to add Apples to Oranges, than you are to add Count of Apples to Count of Oranges. And that also holds true for scalar values used for array indexing, etc.
So it seems to me that no language should be called 'strongly typed' if it doesn't include a complete type system for scalar types.
Re: (Score:3, Interesting)
In other words, since they are only compiling to byte code, and Oracle doesn't have any patents on that, and they can't (nor desire) to take away people's ability to use the JVM, this isn't a problem.
The misconception is that if Google hadn't used J
Re: (Score:3, Interesting)
It is rather questionable if JIT related patents can hold up in a courtcase, JIT compilation has been around since the 70s Smalltalk and Lisp have been using it for decades.
Re: (Score:2)
But look at the picture, if you recognize half those languages, you are pretty good. The languages most of use daily weren't even dreamed of when that picture was made. And so it goe
Re: (Score:2)
Ada is named after a real person, Ada Byron, Countess of Lovelace, therefore should not be typed in all caps. thx
Re: (Score:2)
why in the hell do we need to keep inventing new programming languages?
On one hand, the ones we have are not perfect. On the other hand, there is as yet no agreement as to what a perfect one would look like. Hence many people take many different ways towards what they see as perfection.
On the other hand, there are still quite a lot unresolved language design problems - mainly to do with type systems. Until those are dealt with, it's not clear if perfection is even attainable.
Re: (Score:3, Informative)
if a type is EVER inferred, then the language is NOT statically typed. just because some preprocessor interpreter assigned a static type heuristically doesn't mean the language has anything to do with static typing... in fact, if the language ever infers type, that has EVERYTHING to do with DYNAMIC typing.
You might want to go tell the authors and users of ML (incl. OCaml) and Haskell that they're using dynamically typed languages. Somehow I'm sure they will be very open to this idea.
Re: (Score:2)
Slashdot used to appeal to the technically literate. *sigh*
Re: (Score:2)
Apart from the way the names 'Gosu' and 'Go' overlap and are both derived from the board game, what similarities do you see between the gosu-lang.org and the golang.org websites?
Re: (Score:2)
After briefly glancing through the docs, this language has absolutely nothing to do with Go. I'm not even sure what you mean by "lift of the website" in this context. The design is completely different, and so is the contents.
Re: (Score:2)
Re: (Score:2)
Jepp the dreadful lisp syntax drove me away from clojure, how can anyone write a big system with such a mess of a syntax. There are functional languages which are actually readable, lispish languages are definitely not one of those.
Re: (Score:2)
Replacing Java with another JVM language doesn't help you one bit if you have a problem with relying on Oracle software
Re:Wonder how this turns out... (Score:5, Insightful)
You have to be some kind of uber noob to think that Java and the ecosystem it has engendered could ever be called "nothing of value". There are more jobs in Java and open source projects on Source Forge in Java than in any other language. Java is not everyone's cup of tea - neither are other significant languages like C or LISP, but to pretend that Java, like any of these languages offers "nothing of value" is either arrogance or ignorance beyond belief.
I know that /. no longer caters to a technically literate crowd but you take the cake. I feel stupider for even bothering to reply to you.
Re: (Score:2)
Re: (Score:3, Insightful)
It was runnning the original game. You should be aware that 90% of the code that is running is OpenGl and Java does not implement it. It uses a wrapper to the locally available native OpenGl libraries. So the only overhead is the JNI calls, which have been being reduced a lot on recend versions.
The point is: any language can do it reasonably well. 3d is done on the video card, not on the compiler or he VM.
Re: (Score:3, Informative)
Stop spreading the old Java FUD. Please do some research if you feel so strongly about how someone else chooses to do their work. I don't care what languages you use, why should you care what I use?
This is a mature 3D library + engine:
http://www.jmonkeyengine.com/engine-core/ [jmonkeyengine.com]
Re: (Score:3, Informative)
We just released our language, and are excited about it.
Re:Alright! (Score:4, Insightful)
Convince me Scala is better than Haskell. Convince me cucumbers are better than green peppers. Convince me a bucket of dirt is better than a pile of gravel.
He doesn't have to convince you of anything, because obviously you have already picked your preferred language and think that anything else is useless.
Re: (Score:2)
No, this is from Guidewire Software. It's says right there in the first two words. It's licensed under the Apache license.
But it's still free (in both senses of the word), so I don't get GP's complaint.
Re: (Score:2)
"But it IS a piece of Gosu!"
Don't worry: the language will probably be cancelled before it has a chance to really get going.
Anyway, that was my first thought too, then I wondered if it was an invitation to Oracle's lawyers...?
Re: (Score:3, Informative)
The JVM runs in more systems than the CLR. Assuming it's not too big, you could possibly use it on Android in the near future.
Re: (Score:2)
"How many times have you really used this fall through feature?"
All the time actually. Almost every switch I write has multiple cases which all require the same code executed (or not). If you've never come across this scenario then all I can think is you must just do toy coding.
Re: (Score:2)
Re: (Score:3, Interesting)
Really...isn't it time to rethink all of these different, but same (except for the whacko Python,PHP stuff) and come up with one standard language?
Not just "no", but "hell no". While all of those are Turing complete, I guarantee that you would not want to use Visual Basic to solve the same kinds of problems you'd want to use ML or Prolog for. Very few of the languages you list ("C+"? Heh!) are just minor variations on the others. Their are real, substantial differences between the approaches they take, and things like type systems and garbage collection have implications a lot deeper than just picking which syntax to use for assignment (which I don't
Re: (Score:3, Interesting)
Since I am not CS person (Business, rather), I won't attempt to to argue with you about that.
However, I think that any reasonable person would recognize that this Tower of Babel approach is holding back software development as a whole, needlessly fragmenting knowledge and impacting the careers of excellent programmers simply because they didn't jump on the latest bandwagon X years ago.
Do you realize that Donald Knuth probably would not be "qualified" for 80% of the job postings on Dice...the man that pract
Re: (Score:3, Insightful)
However, I think that any reasonable person would recognize that this Tower of Babel approach is holding back software development as a whole, needlessly fragmenting knowledge and impacting the careers of excellent programmers simply because they didn't jump on the latest bandwagon X years ago.
A little yes but mostly no. A programming language isn't just syntax, it's the entire ecosystem of libraries, tools, operating system support, university teaching, and available documentation. Just as business/finance/economics has multiple sub-disciplines and "schools" that are appropriate to different business situations, so does each major programming platform lend itself to creating certain kinds of applications. Saying "let's use programming language X to solve problem Y" is just as foolish as insis
Re:Stop It! (Score:4, Insightful)
"Clojure" and "D"?
Just shoot me now.
Why are you so hostile to learning? Clojure is a modern "Lisp done right", with all of the syntactic power of LISP minus quite a bit of historical goop, running on a very modern JVM with the goodies that that provides (the massive portfolio of Java libraries and mostly platform independence). D is a very modern "C++ done right" that is very well-suited for applications where you need the ability to occasionally shoot yourself in the foot (i.e. high performance, constrained memory, low-level access) but most of the time would like to use higher-level conveniences like garbage collection and templates.
One thing about the multiple sub-disciplines and "schools"...they all use English.
Sure, they all use English, but they don't say the same thing. (And actually many of them don't. Business is global these days.)
Re:Stop It! (Score:5, Insightful)
Since I am not CS person (Business, rather), I won't attempt to to argue with you about that.
Here is a business-like analogy: How hard is it to divide roman numerals? It's not easy. There are dozens of rules to memorize in order to make it work. Compare this to using Arabic numerals, where you only have to memorize two rules.
However, I think that any reasonable person would recognize that this Tower of Babel approach is holding back software development as a whole, needlessly fragmenting knowledge and impacting the careers of excellent programmers simply because they didn't jump on the latest bandwagon X years ago.
Yes, this is a big problem. But the issue isn't the "Tower of Babel" so much as a misunderstanding of the domains in which a tool can work well, which ultimately leads to "churn". There is an old joke along the lines of "Any sufficiently complex software project implements a buggy version of half of Lisp". There is some truth to that. Lisp is a language that allows abstraction over basically any term. This is something that imperative/OO programmers want, but they don't know how to say (and they tend to cover their ears screaming "LA LA LA LA LA" when academics tell them the problem was solved in the 1960s). So they build up ad hoc solutions to quantify over specific terms. Each of these operations is potentially tricky and buggy. The "Tower of Babel" is a consequence of this. Some of it is legitimate -- new languages can provide better tools (that is, new ways to quantify) to increase productivity. But benefits only accrue if businesses switch to them, at a potentially high cost.
Re: (Score:3, Funny)
It's happening because languages are nowhere near maturity yet. Give it another 150 years and we'll be down to about 5 or 6 commonly used languages. Right now no one has it adequately right.
Re: (Score:3, Insightful)
In Python:
mycounter = 0
That's not just a syntactic difference, and it's not just assigning a value to a variable. Instead, it's creating an int object with a value of 0 and binding the name "mycounter" to it. Since Python objects have types but variables don't (as they're all basically pointers to objects), there's no type declaration necessary - or even feasible without significant ugliness.
In turn, you're missing my point in that these aren't just cosmetic differences that a little bit of syntax unificati
Inexperienced Programmers (Score:3, Insightful)
Think of all the talent locked up in someone who has done language A for 10 years but is totally useless to you because your project uses language B? The concepts are the same, yet people's knowledge is arbitrarily walled off in this development environment or that environment. How can this be considered good?
Innovation doesn't mean re-inventing the wheel.
Sounds like inexperienced programmers. The first 10 languages you learn are challenging, after that it's all syntax and frameworks.
Now then, some languages are bundled with extremely baroque and quirky frameworks which can suck up most of your development time. But this language is actually doing it right - by being Java-compatible on the JVM, the programmer can recycle his Java Library knowledge. Parrot is another similar approach, where Perl, Python, Ruby, etc. programmers will be able to trade librari
Re: (Score:3, Interesting)
Yes, I am old school. The first languages that I learned were Basic, Cobol, RPG, Fortran, followed by Pascal, C, C++, and some assembler. Then lots more. And frankly, I'm bored. Gee, now we have a language that is 100% compatible with Java! If it's so compatible, how is it different? What are the substantial advantages that it offers that I s