>The main reason so > much software is unusable garbage is that the designers > don't think about what the users need. They dismiss > everyone who doesn't think like them as stupid. If they > think of the users at all, they treat them like children.
Of course, the last (and only) language designed such that users could get right in there and make the application do what they want in language they could understand is, wait for it.......... COBOL. And we all know how much respect that language gets.
It matters who we mean by users. If we mean users of the languages, then if we mean commercially oriented non-COBOL, "it's just a job that pays for Johnny's braces", schulbs, then java has long since been passed the baton. Any replacement for java must, by induction, fill the same needs as COBOL. It's not a coincidence that so much of Sun's efforts have been driven by "enterprisy" considerations. IBM stole the vehicle early on, and Sun acquiesced. The copybook has become the Data Object (no, I'm not joking, I had numerous screaming sessions with those people). And so on.
If we mean users of the applications, then there are too many different types. I, as is well known, tend toward the database centric applications. Game or client or stat or... require different languages. Infrastructure builders, probably another. A single language to fit all needs, well, no.
A language to fill java's primary *use* as neo-COBOL (where it is most widely used), probably not anything. It's too entrenched already, as COBOL before it. There are already thousands of "legacy java application" coders sitting next to their COBOL forebears.
> > > I can easily use Scala with our existing Java code. > > > > Depending on case, it may be more profitable to use > > another language though. > > There was over 500,000 lines when it was last counted (not > counting 3rd party libraries).
> Of course, the last (and only) language designed such that > users could get right in there and make the application do > what they want in language they could understand is, wait > for it.......... COBOL. And we all know how much respect > that language gets.
That might have something to do with how badly it failed at that goal. Don't get me wrong. COBOL was really innovative at the time. But there was nothing out there that compared to that the designers could learn from. They were blazing trails. Anyone who thinks that COBOL is understandable is sorely confused. It uses natural language words but that doesn't mean that it's written in English. Most of the statements are nonsensical or meaningless in plain English.
> It matters who we mean by users. If we mean users of the > languages, then if we mean commercially oriented > non-COBOL, "it's just a job that pays for Johnny's > braces", schulbs, then java has long since been passed > the baton. Any replacement for java must, by induction, > fill the same needs as COBOL.
Have you actually ever done any development in COBOL or Java? If you think they are similar, you should disabuse yourself of that notion.
> A language to fill java's primary *use* as neo-COBOL > (where it is most widely used), probably not anything. > It's too entrenched already, as COBOL before it. There > e are already thousands of "legacy java application" > coders sitting next to their COBOL forebears.
What of it? There are also Perl legacy coders, C++ legacy coders, SQL / stored procedure legacy coders. Name a language that's been around for 10 years and there are legacy coders using that language.
I pride myself on being a bit of a polyglot programmer, even having the misfortune to work with SAP ABAP at one point *shudder*
There are definitely languages that just appeal to me for their elegance, such as smalltalk and haskell. even the prototype approach of Javascript has it's merits. Despite this (or maybe because of it) I tend to first solve a problem in general terms and then map it to whatever language I'm using.
What I find important to me with this approach is: - How easy will it be to deploy, is there going to be a ton of effort involved in getting the necessary environment set up? - How easily can I migrate my development or production environment to another platform. - How much of the job can I do with 3rd party libraries. The more, the better. - How useful are the resources to help me diagnose a problem if one should come up? - How closely does the language syntax map to my mental model? Functional concepts, traits, and a robust type system are a real bonus here, as is language support for properties. Static methods and over-the-top exception handling boilerplate are just a pain. In my mental model, when I call a function I'll do so with a very specific thing, such as a customer instance, this does not fit so cleanly with dynamic languages.
Yes, Haskell is more elegant that Scala in many ways, but given all of the above considerations then Scala easily comes out on top.
(U) It is necessary to separate what you enjoy doing (learning different languages - this can be the case when you are a consultant with relatively short assignments or a lecturer in the university) or what you are required to use for your everyday work based on the company policies and preferences. In the latter case you are not in the position to say that you want to use this or that. You are just using what you are told to use. In that case you are close to the position of the 'legacy' programmer. You can try to learn new languages at your free time (if you have one), but without actual work doen with any programming language you forget what you have learned and spent time on. In some cases tasks can help with choosing the right environment for development (including programming languages and frameworks). In other cases customers dictate what you need to use.
> You can try to learn new languages at your free time > (if you have any), but without actual work done with > any programming language you forget what you have > learned and spent time on.
Open source is probably the rest route for anyone in this situation but keen to learn. I'd highly recommend it.
> Have you actually ever done any development in COBOL or > Java? If you think they are similar, you should disabuse > yourself of that notion.
Both, though as little COBOL as possible. My point is not that they resemble each other in either semantics or syntax, but that they do implement the dumbData/smartCode paradigm in the enterprise. What was once done in COBOL is now done, with identical datastore thinking, in java.
> What of it? There are also Perl legacy coders, C++ legacy > coders, SQL / stored procedure legacy coders. Name a > language that's been around for 10 years and there are > legacy coders using that language.
In discussing what language should/could be the successor to java, that successor will emerge organically and will follow very closely the entrenched paradigms of java. Those paradigms are enterprise COBOL-ism, not even the object oriented facilities of the language (happily perverted by the dataObject/actionObject approaches of enterprise frameworks), much less any functional language semantics. Such concerns are far outside the mainstream.
Compare what OO is said to be about: data and function together communicating by message passing; with what really happens in enterprise frameworks, which is where 99.44% of java is actually used.
> In discussing what language should/could be the successor > to java, that successor will emerge organically and will > follow very closely the entrenched paradigms of java.
I know it's not strong as arguments go, but I think this is one of the biggest things that Scala has going for it. Developers can very quickly start using the language as though it was a cleaner version of Java, with which they are very familiar. Functional concept can then be introduced gradually, without an all-or-nothing paradigm shift.
I would not bet on the language that is built on top of another one without its own run-time that it can survive due to dependencies on JVM, etc. One day the vendors can decide to stop any further support for JVM and provide any new versions that would fix the existing bugs. What will happen to Scala then or will it die earlier as many other attempts to create some new programming language did? Will it stay at some college professor desktop as Smaltalk did just to make students crazy and force them to learn what they will never use after the college?
> I would not bet on the language that is built on top of > another one without its own run-time that it can survive > due to dependencies on JVM, etc. One day the vendors can
I think running on the JVM is a safe bet for at least another decade.
> I would not bet on the language that is built on top of > another one without its own run-time that it can survive > due to dependencies on JVM, etc.
Scala can compile to both Java bytecode and Microsoft's CLR. There's also an implementation of the JVM available over LLVM.
So no, I'm not worried about the language dying due to the VM dying.
Flat View: This topic has 59 replies
on 4 pages
[
«
|
1234
|
»
]
Previous Topic
