Live data from Hacker News

Scala Considered Harmful For Large Projects?

kirkwylie.blogspot.com

51–57 of 57 posts

Re: Scala Considered Harmful For Large Projects?

#51

Earlier quoted context omitted.

??? I'm not trashing Java. Did you read the article? I was making an analogy between the risk of having a language like Scala, which would mean there was stuff the Java-only people would not understand (which is what the article claims), with the black box auto-generated code produced by early J2EE (which is similarly a no-fly zone). Believe me, you'll know when I'm trashing Java, because I'll use the g word.

"...with the black box auto-generated code produced by early J2EE" If this comparison were analogous, your point would make no sense, since it would boil down to in the bad old days, we got stuck with code we couldn't understand and lived with it, so now, code we can't understand isn't a problem . And it's not analogous. We're not talking about black-box generated code nobody on the project understands, but instead p…

Not to pick on you, but I've worked on plenty of Java projects where there were sections of the code that some of the programmers either didn't understand or didn't want to touch with a bargepole because they were 'too scary'.

Taking the example of J2EE, on a sufficiently large J2EE project (where 'sufficiently large' is 3 or more people) it would be trivially easy for a Java programmer who didn't know J2EE to work on it - since there's usually a lot more to it than just the back end persistence bit. (Front end, middle layer services, business illogic etc)

Or say they are using both an obscure database and hibernate and I spend a significant amount of time trying to get them to agree on how date formats will be read and written (don't laugh, nobody else could figure it out). When I do get it working, does everybody else on the project magically absorb this newfound expertise via osmosis or something? Don't be ridiculous! Only I have the understanding of it, and if the others know what is good for them they will not fiddle with it.†

Naturally I'll liberally sprinkle it with comments like:

// if you want to retain your SAN points, don't mess with this

In fact, this thing of someone working on something that is really tricky and then when they do get it working warning off the other programmers from messing with it is extremely common in larger projects. One of the benefits of OO code is that you can segment the 'nasty stuff' off from the rest of the code so that it can be safely ignored. And this doesn't just apply to senior programmers doing stuff too scary for the junior programmers, it can work the other way too - as a senior member of the team I'm quite happy to let someone junior with lots of 'fire in their belly' tackle the ugly ugly task of getting the config files set up, and if they've done it right I never even have to look at them (don't be outraged, it's called delegation).

If you have to twiddle your ant script every time you want to compile your code, you ain't doing it right.

---

† the corollary of this is: that there is always a fiddler.

But when they break it you're allowed to laugh at them and then tell them to put it back the way it was when they found it

Re: Scala Considered Harmful For Large Projects?

#52
post #39

Earlier quoted context omitted.

One of my CS professors made the remark that C++ seemed like it had been designed by people who thought that there was a tax on keyboard symbols. So rather than using new symbols that were on a standard keyboard but not part of the language already, they just reused the old symbols either as is or in strange new combinations. When I look at Scala it gives me that same feeling. Additionally, they seem to come from the…

I don't see any symbols on my keyboard that weren't already used in C except @ and ` (backtick.) P.S. I forgot about $.

Let's assume you're right. You also need to consider the composite symbols. Example: >> already has a meaning in C++ so instead of reusing the exact same combination why not invent a new symbol (made up of two or more symbols) for sending Strings to the output?

E.g. I don't know, something that looks a bit more like the terminal prompt

?>

or

$>

or even go wild and crazy

$$

If you say "lol u nuub, operater overloading!" then I would reply if operator overloading is good, then having more operators defined at the language level and thus available for overloading is better, yes?

Re: Scala Considered Harmful For Large Projects?

#53
post #39

Earlier quoted context omitted.

I don't see any symbols on my keyboard that weren't already used in C except @ and ` (backtick.) P.S. I forgot about $.

Let's assume you're right. You also need to consider the composite symbols. Example: >> already has a meaning in C++ so instead of reusing the exact same combination why not invent a new symbol (made up of two or more symbols) for sending Strings to the output? E.g. I don't know, something that looks a bit more like the terminal prompt ?> or $> or even go wild and crazy $$ If you say "lol u nuub, operater overloading…

The operators >> and >). They're actually a surprisingly intuitive notation because the arrows point in the direction of data movement (since the stream is always to the left). There aren't many other notations that can be as intuitive and bidirectional. The next obvious notation, -> and is already a legal operator on an object.

There are many valid criticisms of C++. I don't think not using enough keys on the keyboard is one of them.

Re: Scala Considered Harmful For Large Projects?

#54

Earlier quoted context omitted.

If your code isn't readable right off the bat, you're doing it wrong. At one place I worked I had a BA who was nosey and came and tried looking over my shoulder at one point at some file manipulation code I'd written. Now I used to put a lot of time and effort into writing nice neat code, but this was something for me alone, so I hadn't bothered putting in the comments that I normally would. Anyway, because I wanted…

I think there's a confusion of micro- and macro-readability in this thread. You are describing micro-readability, IMO. I've read lots of code where it was clear what each line of code did, but not at all clear what the end result was, or why it was being done. Furthermore, there's dramatic disagreement about what is actually more readable. I have an ongoing debate with a coworker about the relative readability of wid…

I personally dislike symbol to proc for a reason I can't fully put into words so I would say widgets.any?{|x| x.can_frobnicate?}

Re: Scala Considered Harmful For Large Projects?

#55
post #48

Earlier quoted context omitted.

Regarding 1, there are languages that do not have a clear, unambiguous (to my reading, formalized ) grammar yet possess compilers. Examples include classical FORTRAN, Forth and (if I'm feeling particularly trollish today) C++.

Fair enough. But in that case, the entire argument is moot. After all neither Java nor Scala (as far as I know) are formalized. :-)

The Scala language report does include an Extended-BNF syntax for the language, weighing in at 7 pages.

Re: Scala Considered Harmful For Large Projects?

#56

Earlier quoted context omitted.

I think there's a confusion of micro- and macro-readability in this thread. You are describing micro-readability, IMO. I've read lots of code where it was clear what each line of code did, but not at all clear what the end result was, or why it was being done. Furthermore, there's dramatic disagreement about what is actually more readable. I have an ongoing debate with a coworker about the relative readability of wid…

I personally dislike symbol to proc for a reason I can't fully put into words so I would say widgets.any?{|x| x.can_frobnicate?}

it's certainly a little syntactically ugly. I'd much prefer it if functions were first-class and I could write something like "widgets.any? can_frobnicate?" or "any widgets can_frobnicate?".

Re: Scala Considered Harmful For Large Projects?

#57

Earlier quoted context omitted.

"...with the black box auto-generated code produced by early J2EE" If this comparison were analogous, your point would make no sense, since it would boil down to in the bad old days, we got stuck with code we couldn't understand and lived with it, so now, code we can't understand isn't a problem . And it's not analogous. We're not talking about black-box generated code nobody on the project understands, but instead p…

Not to pick on you, but I've worked on plenty of Java projects where there were sections of the code that some of the programmers either didn't understand or didn't want to touch with a bargepole because they were 'too scary'. Taking the example of J2EE, on a sufficiently large J2EE project (where 'sufficiently large' is 3 or more people) it would be trivially easy for a Java programmer who didn't know J2EE to work o…

"I've worked on plenty of Java projects where there were sections of the code that some of the programmers either didn't understand or didn't want to touch with a bargepole because they were 'too scary'."

And this is undesirable, is it not? Encapsulation aside, sometimes people get shuffled around in projects.

It's one thing to say, "OK, junior developers, don't mess with the tricky stuff in this project." It's another to say, "OK, I've decided to start writing this part of the project in a language the rest of you don't actually know."

Post reply on HN