The Artima Developer Community
Sponsored Link

Weblogs Forum
The Positive Legacy of C++ and Java

210 replies on 15 pages. Most recent reply: May 8, 2009 11:50 PM by Daesung Park

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 210 replies on 15 pages [ « | 1 ... 11 12 13 14 15 | » ]
Krisztian Sinka

Posts: 30
Nickname: skrisz
Registered: Mar, 2009

Re: The Positive Legacy of C++ and Java Posted: Apr 15, 2009 10:23 PM
Reply to this message Reply
Advertisement
> When I was asking for examples, I was really hoping to see
> some code instead of English :-)

Look at the Boost Spirit doc site at:

http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/doc/introduction.html

Just compare the EBNF with the Spirit syntax. Read trough the page to learn why are there subtle differences.

If it is not convince you then I would like to see the example written in legal C++ not using operator overloading but “plain” member functions. ;-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 16, 2009 7:51 AM
Reply to this message Reply
> I concede that overloading [] for maps makes the code a
> bit easier to read, although put() is not particularly
> hard to decipher either.

A bit off topic but what's really cool about the way this works in python is that lists and maps have a consistent "interface".

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 17, 2009 2:56 AM
Reply to this message Reply
> You keep invoking the "Java is for dumb programmers" fallacy. Why?
I don't think Java is for dumb programmers, or at least I wouldn't want this to be the case. I just think that anybody arguing against adding more advanced features to Java tends to make it a language for stupid programmers - not even so much stupid as lower-skilled.

> I think that there will be a shift away from this but I could be wrong.
> There are real gains to be had by moving away from Java. Right now none
> of the languages are enticing enough to IT shops but that will change, I
> expect.
1) Yes and no. Surely a next big thing in programming languages will come some day, but enterprises, as they get more mature regarding IT stuff, heavily support evolution instead of revolution. Any revolution means high costs, whereas evolution is much cheaper. So the process of moving away from Java will be a slow one, unless for instance MS offers to pay for migrating all Java apps to .Net, and makes .Net open source and available cross platform, which is already SciFi.

2) Unfortunately, it isn't IT shops that decide upon technology. And non-IT shops, i.e. customers, don't make decisions based on language issues alone - what they use is the TCO. The sheer numbers of Java programmers on the market, plus availability of tools, libraries, application servers and overall infrastructure components, many of them free, make Java an attractive technology for enterprise applications, in spite of Java having its quirks. The only alternative is .Net, which is however limited to Windows as an OS, which brings significant HW and SW limitations with it (if we don't consider virtualization), and which still isn't that well covered with server-side technologies, thus being a less attractive technology for an enterprise infrastructure, IMO. Essentially, I think it's the robusntess of the ecosystem around a language that makes it succeed or vanish. The ecosystem around the JVM and Java is quite large and stable, I think.

> A little off-topic but if the only reason to support Java is for your
> customers, have you considered pre-processors or IDE extensions?
Yes. I've not yet come across something smart enough, on one hand, and on the other hand it gets too complicated to be feasible the moment programmers outside your team get their hands on code you delivered - remember, the code belongs to the customer, so whoever is hired by the customer can change it in any way he/she wants. Also, customers sometimes (we try to avoid it if possible) sometimes give you existing code for maintenance projects, and in such cases such tools are a lot less useful, if at all.

On the other hand, IMO something requiring tools to be used is not a smart technology choice. Every additional component in the process is an additional potential point of failure. If the ppl providing the tools fail to keep up with development of the language or of the platform, switching tools can be complicated or impossible, or at least extremely expensive.

Third, why would a small SW dev shop support a language other than for providing services based on it to customers?

> Even if you don't have to use a feature, it affects you. If gotos were
> allowed, you would have to understand how they are being used in any
> code that you had to deal with that used them.
1) I'd rather learn to understand goto, even if I wouldn't use it, than give up operator overloading, if I had the choice. It's the lack of choice that bothers me. Besides, there's a difference of effort needed to learn to understand what goto does in code you didn't write and to understand how to use goto efficiently (you can replace goto with operator overloading or generics, the meaning of what I want to say is the same).

2) It seems to me you think standards cannot and are not ever enforced. If you have a coding standard which bluntly states that goto should never be used, the size of the team is IMO irrelevant for enforcing the standard. Although also IMO having such a rigid standard is stupid, and code reviews should be used to allow or reject a goto on a case by case basis. It's also a bit off topic, but I remember a Linus Torvalds quote: "Dijkstra probably hates me" - related to the use of goto in the Linux kernel code ver. 1.4.something. I just looked, gotos are still used in the same file, although the comment is no longer there.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 17, 2009 3:11 AM
Reply to this message Reply
> > You keep invoking the "Java is for dumb programmers"
> fallacy. Why?
> I don't think Java is for dumb programmers, or at least I
> wouldn't want this to be the case. I just think that
> anybody arguing against adding more advanced features to
> Java tends to make it a language for stupid programmers -
> not even so much stupid as lower-skilled.

I think there is an important distinction between features initially present in a language (or added at a very early stage) and adding features to a mature language. It isn't easy to add features to a mature language without some degree of compromise and/or breaking existing code.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 17, 2009 3:19 AM
Reply to this message Reply
I've just had to hunt through some old C++ code with just a text editor (i.e. I didn't have the code in a C++ aware IDE). All the file names bore only a weak relationship to their content. The rigid naming convention required by Java makes this task so much easier. Should future languages follow the Java pattern? I notice that Scala recommends but doesn't require file names to match the classes.

Kenneth Uildriks

Posts: 1
Nickname: kennethuil
Registered: Apr, 2009

Re: The Positive Legacy of C++ and Java Posted: Apr 18, 2009 9:46 AM
Reply to this message Reply
I still like C++.

Garbage collection may use less CPU than reference counting, but reference counting more aggressively conserves memory. Sometimes memory is your bottleneck; on my Virtual Private Server, for instance, I'm more constrained on memory than on CPU, so aggressively conserving memory at the expense of CPU cycles is a good tradeoff.

I also like to use a simple memory pool library that lets me automatically manage the lifetime of a whole bunch of objects without having to track the lifetime of each individual one. That gives me slightly less agressive conservation of memory (but still better in that regard than garbage collection), but uses zero CPU cycles along with zero manual memory management. The only time the memory pool doesn't work well is when an object is shared among several threads, in which case I reach for reference counting.

C++ templates open up a combination of more flexible typing without sacrificing compile-time checking.

That said, there's some room for improvement:

1. C++ needs real modules that can contain templated classes and functions and that do away with the C preprocessor.

2. C++ needs a better grammar. If the source code is less ambiguous and easier to parse, tools to work on your source code (including but not limited to compilers) proliferate faster.

3. Const propagation needs to be less manual and less painful. I'm thinking something like a "propagated const" concept, so you can define a function like this:

propconst char* find(propconst char* haystack, const char* needle)

Then you can pass it a const char*, and get back a const char*, or pass it a char* and get back a char*, and you won't have to cast away constness either in the body of the function or its caller.

4. Pointers to an arrays need to be semantically distinct from pointers to individual objects, and they need to carry a length as well as an address. That way you can pass them around without needing a separate channel for the length or needing to encode the length in the data. And then null terminated strings can die a well-deserved and long overdue death.

So the function above would really be defined as:

propconst char[] find(propconst char[] haystack, const char[] needle)

with the char[] having both an address and a length in it, and the return value representing a subarray within the original array.

With the help of LLVM (http://www.llvm.org/), I'm in the process of building a "better C++" with these improvements.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: The Positive Legacy of C++ and Java Posted: Apr 19, 2009 5:08 AM
Reply to this message Reply
I've wondered about that question myself. C# allows file names to be different, but that also allowed it to add on support for partial classes, which makes IDE support/code generation a lot easier. I suppose Java would run into all sorts of trouble because of the tight coupling between file name and class name.

Personally, I think some reasonable relationship makes sense though, it's pretty annoying to have to grep through the whole codebase to find the class you want to take a quick look at. I guess it comes back to ease in team development situations, as James mentioned earlier.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 20, 2009 6:16 AM
Reply to this message Reply
> I've just had to hunt through some old C++ code with just
> a text editor ...
:D Now you probably have a better understanding of why I don't like technologies or solutions which heavily rely on specialized tools, such as IDE plugins.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 20, 2009 6:29 AM
Reply to this message Reply
> I've wondered about that question myself. C# allows file
> names to be different, but ...
Idunno. C# and anything .Net relies heavily on IDE magic, which I find annoying. I like the Java way more, where you get to see all things in code. Essentially, it's no big deal to configure a somewhat smarter text editor like notepad++ or ultraedit to act as a basic IDE for Java. Doing this for any .Net language is IMO more complicated.

> Personally, I think some reasonable relationship makes
> sense though ...
Kinda reminds me of the motivation the maven ppl use for maven relying on convention vs. ant offering full flexibility in how the source tree, libs folder and the like are set up. IMO, it seems it is all a matter of what you want. With ant you can set up things any way you want. With maven, you're bound to some conventions, but maven manages almost all aspects of the build process automatically, requiring only very little manual work.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 20, 2009 6:40 AM
Reply to this message Reply
> > I've just had to hunt through some old C++ code with
> just
> > a text editor ...
> :D Now you probably have a better understanding of why I
> don't like technologies or solutions which heavily rely on
> specialized tools, such as IDE plugins.

While I appreciate the point, I think it is a battle we will ultimately lose.

Also some of my work is mathematical. In this case it doesn't make much sense to document the code with another linearised representation of the formulae (such as TeX) as that will be no more comprehensible to most readers than the source code itself. What it really needs is the conventional 2D maths formulae presentation (which you could generate from TeX, but you won't see that if using an ordinary text editor). So here an advanced IDE which rendered maths found in comments would be useful.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 20, 2009 7:48 AM
Reply to this message Reply
> > You keep invoking the "Java is for dumb programmers"
> fallacy. Why?
> I don't think Java is for dumb programmers, or at least I
> wouldn't want this to be the case. I just think that
> anybody arguing against adding more advanced features to
> Java tends to make it a language for stupid programmers -
> not even so much stupid as lower-skilled.

I think you are right that this is why *some* people don't want these features but for a lot of other people, it's really about managing complexity. Each new feature adds more complexity to the language. If the feature doesn't offer significant specific (and new) advantages, then the Java philosophy is that it's not worth the extra complexity. Again, I'm not sure that operator overloading is correctly excluded. I'm talking about this in general.

> 1) Yes and no. Surely a next big thing in programming
> languages will come some day, but enterprises, as they get
> more mature regarding IT stuff, heavily support evolution
> instead of revolution. Any revolution means high costs,
> whereas evolution is much cheaper. So the process of
> moving away from Java will be a slow one, unless for
> instance MS offers to pay for migrating all Java apps to
> .Net, and makes .Net open source and available cross
> platform, which is already SciFi.

I'm actually envisioning a world where a new language that runs on the JVM and integrates cleanly with Java becomes the next thing. Instead of rewriting all the Java code, the new language would be used to build onto existing Java apps and eventually the Java parts would be rewritten in the newer language. This isn't my idea, obviously. Scala was developed with this vision. Personally, I can't see Scala gaining wide acceptance in IT. The design seems to concerned with pointy-headed concepts and not enough with real day-to-day programmer concerns, although it does offer some real benefits in that area.

> 2) Unfortunately, it isn't IT shops that decide upon
> technology. And non-IT shops, i.e. customers, don't make
> decisions based on language issues alone - what they use
> is the TCO. The sheer numbers of Java programmers on the
> market, plus availability of tools, libraries, application
> servers and overall infrastructure components, many of
> them free, make Java an attractive technology for
> enterprise applications, in spite of Java having its
> quirks. The only alternative is .Net, which is however
> limited to Windows as an OS, which brings significant HW
> and SW limitations with it (if we don't consider
> virtualization), and which still isn't that well covered
> with server-side technologies, thus being a less
> attractive technology for an enterprise infrastructure,
> IMO. Essentially, I think it's the robusntess of the
> ecosystem around a language that makes it succeed or
> vanish. The ecosystem around the JVM and Java is quite
> large and stable, I think.

I agree. I work in a shop with a lot of COBOL and RPG programmers. Management doesn't really want to continue to use COBOL but we have a lot of COBOL code and developers are easy to come by (for now.) What makes it very difficult to get away from COBOL is how poorly it integrates with other languages and tools. Java, IMO, doesn't have this same problem.

> > A little off-topic but if the only reason to support
> Java is for your
> > customers, have you considered pre-processors or IDE
> extensions?
> Yes. I've not yet come across something smart enough, on
> one hand, and on the other hand it gets too complicated to
> be feasible the moment programmers outside your team get
> their hands on code you delivered - remember, the code
> belongs to the customer, so whoever is hired by the
> customer can change it in any way he/she wants. Also,
> customers sometimes (we try to avoid it if possible)
> sometimes give you existing code for maintenance projects,
> and in such cases such tools are a lot less useful, if at
> all.
>
> On the other hand, IMO something requiring tools to be
> used is not a smart technology choice. Every additional
> component in the process is an additional potential point
> of failure. If the ppl providing the tools fail to keep up
> with development of the language or of the platform,
> switching tools can be complicated or impossible, or at
> least extremely expensive.

I was thinking that a tool that allowed you to see a specific method as '+' or '-' in your IDE would be a good fit. The resulting code would look like any other code. The customers would be none the wiser, if it were done well.

> Third, why would a small SW dev shop support a language
> other than for providing services based on it to
> customers?

I don't know. Why are you asking?

> > Even if you don't have to use a feature, it affects you.
> If gotos were
> > allowed, you would have to understand how they are being
> used in any
> > code that you had to deal with that used them.
> 1) I'd rather learn to understand goto, even if I wouldn't
> use it, than give up operator overloading, if I had the
> choice. It's the lack of choice that bothers me. Besides,
> there's a difference of effort needed to learn to
> understand what goto does in code you didn't write and to
> understand how to use goto efficiently (you can replace
> goto with operator overloading or generics, the meaning of
> what I want to say is the same).

But you are missing that the use of these features by others affects you in that it forces you to change how you do things. It's not just about reading their code. You may be forced to use the feature to interact with their APIs.

> 2) It seems to me you think standards cannot and are not
> ever enforced. If you have a coding standard which bluntly
> states that goto should never be used, the size of the
> team is IMO irrelevant for enforcing the standard.

Coming to agreement on what the standards should be is definitely affected by the size of the team. The only solution is to have a dictator and you are in the same situation then that you are in with the JCP (unless you are the dictator.)

> Although also IMO having such a rigid standard is stupid,
> and code reviews should be used to allow or reject a goto
> on a case by case basis.

On a large team, the review teams are not always the same group of people. If you make it up to the review team you end up with highly inconsistent code and frustrated developers because one team approves something one week and the next team rejects the same approach the next week. The uncertainty creates low morale and other problems.

> It's also a bit off topic, but I
> remember a Linus Torvalds quote: "Dijkstra probably hates
> me" - related to the use of goto in the Linux kernel code
> ver. 1.4.something. I just looked, gotos are still used in
> the same file, although the comment is no longer there.

I don't know anything about kernel development so it might be perfectly reasonable in that circumstance. But I know for sure that goto never needs to be used in business logic. There are ways to use goto that are not problematic. They are essentially what the standard structures like loops and methods we use in languages like Java came from. But that's the point, they offer no advantages over these approaches. The only thing they add is the ability to cause confusion and other problems. You lose nothing by excluding them (in a business app.) Personally I don't like having big red buttons that say "don't push" around. If I have to choose between a railing that prevents people from accidentally falling to their death and a sign that says "careful, don't fall", I'll do with the railing every time.

The upshot is that I agree with the Java philosophy in general. Don't add features that don't provide significant and new (and good) abilities. Having lots of different ways of doing the same things just creates inefficiencies. In the case of operator overloading, it probably would have been OK if added in the beginning but would be problematic to add now.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: The Positive Legacy of C++ and Java Posted: Apr 21, 2009 6:23 AM
Reply to this message Reply
> Idunno. C# and anything .Net relies heavily on IDE magic,
> which I find annoying. I like the Java way more, where you
> get to see all things in code.

I definitely agree with you in spirit, but I don't think C# is guilty of this, although MS has been known to do this heavily in the past. Most of the IDE magic has to do with code generation, and almost all that code generation can be done on the command line now. Everything happening in a .NET application is traceable to code, unlike say olden day VB and stuff, where things happened automagically. C# is like Java in that the IDE is not mandatory.

Also, even Java IDEs like NetBeans emit code directly into the source code. However, what appears to be a good improvement in C# with its partial classes, is that it allows for the separation of tool generated code from hand-written code. Mixing this in the same source file can have nasty effects, including accidental overwriting of hand-written code and a lot of tool generated cruft mixing with your code etc. In that sense, C# seems to be at an advantage.

> IMO, it seems it is all a matter of what
> you want. With ant you can set up things any way you want.
> With maven, you're bound to some conventions, but maven
> manages almost all aspects of the build process
> automatically, requiring only very little manual work.

That seems to captures the essence of it. Also has the advantage of making it easier for a new developer to fit into a team, since the conventions are known.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 22, 2009 12:52 AM
Reply to this message Reply
> (..) but for a lot of other people, it's
> really about managing complexity. Each new feature adds
> more complexity to the language. If the feature doesn't
> offer significant specific (and new) advantages, then the
> Java philosophy is that it's not worth the extra
> complexity.

Essentially, I think there are two different, somewhat antagonistic views on a language's development in relation to complexity, that you and I represent.

You'd rather control language complexity than language usage complexity. I would allow language to include any feature, if there's a potential good use for it, and control language usage complexity instead. I think both aproaches work under specific circumstances. A simpler language is probably better in large companies where politics and business issues play a more significant role than technology.

In smaller companies, academia or in small teams inside large companies where agile methods are employed, I think that high language complexity is not an issue, since team members interact strongly, knowhow is disseminated quickly and more complex, not very often used language features get to be used in a smart way when they are needed.

> But you are missing that the use of these features by
> others affects you in that it forces you to change how you
> do things.

It does not affect me personally, it affects the whole team/company, or maybe just one single project. But using one API or not, allowing a specific language feature in a body of code or not are all decisions which should be taken anyway, not in relation to a language's complexity and possibilities, but in relation to the project/code at hand. Only, not having certain features in the language limits the decisions the team, the project manager or whoever is in charge can make, potentially degrading code quality at least for some projects.

> (...) But I know
> for sure that goto never needs to be used in business
> logic.

I just thought of an example where using goto is a big nono from a technology point of view but may be reasonable to be used, even required, from a business point of view.

Say you work with a customer on complicated business processes which change. Maybe not very often, but still. THe user's way of explaining the processes to you is numbered lists of steps to be performed. EVery so often in such lists you have phrases like " if <condition> then go to step <number>". Due to process complexity, long work together and so on, the customer starts to be your primary QA source. He even gets to see the source code, and to understand it, mostly. He sometimes even dares to make small changes to the algorithms directly in code. For this to work, your implementation has to look very much alike with what the customer tells you as numbered lists of steps. Since the customer uses gotos in his lists, you need to use them in your code. Even if this way the implementation gets ugly and unmaintainable.

> Coming to agreement on what the standards should be is
> definitely affected by the size of the team. The only
> solution is to have a dictator and you are in the same
> situation then that you are in with the JCP (unless you
> are the dictator.)

Not sure I agree with you. Voting on standards in a company is nonsense to me. The company has a management system which should designate decision makers for technical issues too. With such a system, team size is IMO irrelevant.

> On a large team, the review teams are not always the same
> group of people. If you make it up to the review team you
> end up with highly inconsistent code and frustrated
> developers because one team approves something one week
> and the next team rejects the same approach the next week.

That's just a consequence of lacking standards. IMO, reviews should be something systematic, that just checks the code against some well defined criteria which cannot be checked by a lint-like tool. (There's a book I think is perfect as a starting point for doing code reviews: A.J. Riehl's OO Design Heuristics. Some heuristics contradict themselves, but reviewing code only against these heuristics is IMO unlikely to yield different review results from different teams.)

> The upshot is that I agree with the Java philosophy in
> general. Don't add features that don't provide
> significant and new (and good) abilities. Having lots of
> different ways of doing the same things just creates
> inefficiencies.

So, if I understand you right, while loops should vanish, right? After all, you can rewrite any while loop as a for.

IMO, adding features to a language makes sense when this adds to the expressivity of the language, without a comparable decrease in readability. Templates are one such example: the decrease in readability is IMO small, but the increase in expressivity is huge. Operator overloading is IMO in the same class.

Another case of big nono in Java, IMO stupidly so: explicit destruction. This would IMO also be useful, precisely in order to allow you to say something that at the moment is impossible in Java: "this object is no longer valid, simply because I destroyed it." You have many business situations in which you want to destroy a business object: a company that went broke, a bag of outdated banc notes, papers you run through the paper grinder. But there's no convenient, out of the box way of modelling these operations in Java without explicit destruction. Whoever kept a reference to the banc notes before you burned them can still use them for valid payments afterwards.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 22, 2009 1:02 AM
Reply to this message Reply
> In smaller companies, academia or in small teams inside
> large companies where agile methods are employed, I think
> that high language complexity is not an issue, since team
> members interact strongly, knowhow is disseminated quickly
I think you need to consider the duration of the project as well (or perhaps simply count all the people who have ever contributed code to it).

> Another case of big nono in Java, IMO stupidly so:
> explicit destruction. This would IMO also be useful,
> precisely in order to allow you to say something that at
> the moment is impossible in Java: "this object is no
> longer valid, simply because I destroyed it." You have

You can implement a "close" method. What you can't do is have the memory reused while references to it still exist.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Positive Legacy of C++ and Java Posted: Apr 22, 2009 6:31 AM
Reply to this message Reply
> You'd rather control language complexity than language
> usage complexity. I would allow language to include any
> feature, if there's a potential good use for it, and
> control language usage complexity instead. I think both
> aproaches work under specific circumstances. A simpler
> language is probably better in large companies where
> politics and business issues play a more significant role
> than technology.

I agree. I don't think Java is the best language in those situations. It's niche is in companies with highly transient programmers (e.g. contractors). Because the rules don't change much, you don't have to spend as much time bringing everyone up to speed. Now, whether this is a good way to run a development shop is another question but these shops are very common. Even if it's not a good idea, it may be unavoidable for a number of companies.

> It does not affect me personally, it affects the whole
> team/company, or maybe just one single project. But using
> one API or not, allowing a specific language feature in a
> body of code or not are all decisions which should be
> taken anyway, not in relation to a language's complexity
> and possibilities, but in relation to the project/code at
> hand. Only, not having certain features in the language
> limits the decisions the team, the project manager or
> whoever is in charge can make, potentially degrading code
> quality at least for some projects.

If you are on a team that is organized and run well enough to manage this on it own, more power to you. But a lot of team don't. It might be the case that your customers are largely unable to. So they want Java because it works for them.

> I just thought of an example where using goto is a big
> nono from a technology point of view but may be reasonable
> to be used, even required, from a business point of view.
>
> Say you work with a customer on complicated business
> processes which change. Maybe not very often, but still.
> THe user's way of explaining the processes to you is
> numbered lists of steps to be performed. EVery so often in
> such lists you have phrases like " if <condition> then go
> to step <number>". Due to process complexity, long work
> together and so on, the customer starts to be your primary
> QA source. He even gets to see the source code, and to
> understand it, mostly. He sometimes even dares to make
> small changes to the algorithms directly in code. For this
> to work, your implementation has to look very much alike
> with what the customer tells you as numbered lists of
> steps. Since the customer uses gotos in his lists, you
> need to use them in your code. Even if this way the
> implementation gets ugly and unmaintainable.

Frankly, I can't think of a worse reason to use gotos in a business application. The developer/analysts job is to understand the processes and translate them into software. Aside from that, there are lots of ways to model what you describe without using gotos.

> > Coming to agreement on what the standards should be is
> > definitely affected by the size of the team. The only
> > solution is to have a dictator and you are in the same
> > situation then that you are in with the JCP (unless you
> > are the dictator.)
>
> Not sure I agree with you. Voting on standards in a
> company is nonsense to me. The company has a management
> system which should designate decision makers for
> technical issues too. With such a system, team size is IMO
> irrelevant.

So what's the difference if a decision maker decides a team will not use certain features and if a decision maker decides to use a language that doesn't allow those features? You also seem to ignore that coming up with these standards takes time/costs money. A lot of companies would rather just not have to deal with that. My experience is also that these homegrown standard are often really poorly designed. I've seen standards that forced bad practices to be used.

> > On a large team, the review teams are not always the
> same
> > group of people. If you make it up to the review team
> you
> > end up with highly inconsistent code and frustrated
> > developers because one team approves something one week
> > and the next team rejects the same approach the next
> week.
>
> That's just a consequence of lacking standards. IMO,
> reviews should be something systematic, that just checks
> the code against some well defined criteria which cannot
> be checked by a lint-like tool. (There's a book I think is
> perfect as a starting point for doing code reviews: A.J.
> Riehl's OO Design Heuristics. Some heuristics contradict
> themselves, but reviewing code only against these
> heuristics is IMO unlikely to yield different review
> results from different teams.)

I'm confused because I was responding to this: "Although also IMO having such a rigid standard is stupid, and code reviews should be used to allow or reject a goto on a case by case basis." So if having rigid standards is stupid (it doesn't get much more rigid than automated standards checking) and the problems I have described are a result of not having standards, which are you advocating?

> > The upshot is that I agree with the Java philosophy in
> > general. Don't add features that don't provide
> > significant and new (and good) abilities. Having lots
> of
> > different ways of doing the same things just creates
> > inefficiencies.
>
> So, if I understand you right, while loops should vanish,
> right? After all, you can rewrite any while loop as a
> for.

It doesn't have to be draconian. There are certain things that are unnecessary but make things easier for developers (such as operator overloading). I actually wouldn't miss the while loop much (I almost never use it) but that's beside the point. The point is that if you don't limit the number of features in a language, you end up with something like Perl which is almost unusable for team development.

> IMO, adding features to a language makes sense when this
> adds to the expressivity of the language, without a
> comparable decrease in readability. Templates are one such
> example: the decrease in readability is IMO small, but the
> increase in expressivity is huge. Operator overloading is
> IMO in the same class.

I think this is a very reasonable argument. It something that we can talk rationally about. My only point in this exchange is that the ad hominem attack "Java is for stupid programmers" and it's brethren is not a rational argument.

Flat View: This topic has 210 replies on 15 pages [ « | 11  12  13  14  15 | » ]
Topic: Should I use a netbook as my main development platform? Previous Topic   Next Topic Topic: Social Newsfeeds: The Next Big Thing

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use