Scala, a Statically Typed, Functional, O-O Language

inkslinger77 notes a Computerworld interview with Martin Odersky on the Scala language, which is getting a lot of attention from its use on high-profile sites such as Twitter and LinkedIn. The strongly typed language is intended to be a usable melding of functional and object-oriented programming techniques. "My co-workers and I spend a lot of time writing code so we wanted to have something that was a joy to program in. That was a very definite goal. We wanted to remove as many of the incantations of traditional high-protocol languages as possible and give Scala great expressiveness so that developers can model things in the ways they want to. ... You can express Scala programs in several ways. You can make them look very much like Java programs which is nice for programmers who start out coming from Java. ... But you can also express Scala programs in a purely functional way and those programs can end up looking quite different from typical Java programs. Often they are much more concise. ... Twitter has been able to sustain phenomenal growth, and it seems with more stability than what they had before the switch, so I think that's a good testament to Scala. ... [W]e are looking at new ways to program multicore processors and other parallel systems. We already have a head start here because Scala has a popular actor system which gives you a high-level way to express concurrency. ... The interesting thing is that actors in Scala are not a language feature, they have been done purely as a Scala library. So they are a good witness to Scala's flexibility..."

Comments

pronounced ...

[neonprimetime]

... skah-lah not scale-la

Re:pronounced ...

[Profane MuthaFucka]

Same difference. You say potato, I say you're an asshole.

Re:pronounced ...

[binarylarry]

ah fuck why did I hit "troll" instead of funny.

Undoing...

Wanted: Scala Expert

[sycodon]

Scala Programmers: $35K - $45K

Our company is looking for motivated individuals with 5 + years in depth experience with Scala.
Must be familiar with all aspects of O-O Languages.

We are an equal opportunity employer.

Re:Wanted: Scala Expert

[Anonymous Coward]

I'm getting a kick out of all the ACs whooshing eachother.

Re:Wanted: Scala Expert

[infinite9]

$35K - $45K

I didn't know JP Morgan Chase was using Scala. (rolls eyes)

Re:Wanted: Scala Expert

[sycodon]

In that case, I should have written 7 years experience.

Re:Wanted: Scala Expert

[JAlexoi]

Why only 5? Why not 7? We seem to love that number. Even Win7, sounds better with 7 in it :)

Re:Wanted: Scala Expert

[sycodon]

I should have said 10 years because one AC said it has been around since 2003.

Re:Wanted: Scala Expert

[Thuktun]

Since Scala's been out since early 2004, it's entirely possible to have had five years of experience with it.

Re:Wanted: Scala Expert

[Anonymous Coward]

*Whoosh!*

Re:Wanted: Scala Expert

[__aasqbs9791]

Did he also need mastery of C#, Java, Perl, Ruby, and Assembly? I saw one of those (maybe without the Assembly requirement, like it matters) earlier this year. It was for $10/hour though. (o_0)

Re:Wanted: Scala Expert

[Anonymous Coward]

*whoooooooosh*

Re:Wanted: Scala Expert

[IRWolfie-]

$10/hour, thats bad, right? (ignorant european)

Re:Wanted: Scala Expert

[__aasqbs9791]

That mastery of that wide a range of skills? I'd sure say so. Even just for familiarity with all of them them (and master of one) I'd say it is still ridiculously low. Maybe that's just me, but I seriously doubt it.

Re:Wanted: Scala Expert

[larry bagina]

Minimum wage is somewhere around $6-7 an hour. Most $10/hour jobs don't require any skill or education (or thinking).

Re:Wanted: Scala Expert

[PincushionMan]

Unfortunately, not for some poorer sections of the central US, especially those near a college town.

Re:Wanted: Scala Expert

[jonaskoelker]

He obviously meant 10+ years!

Re:Wanted: Scala Expert

[webreaper]

I interviewed somebody in 2007 who claimed they'd had 7 years .Net experience.

Re:Wanted: Scala Expert

[Thuktun]

Yes, that's better.

Re:Wanted: Scala Expert

[Thuktun]

Since VS.NET was released in 2001, if they had been involved in its development, that would also be possible, though granted somewhat unlikely.

Re:Wanted: Scala Expert

[joeyGibson]

Is that a joke? $35K - 45K for 5 years of Scala? What do you pay for 5 years of Java, then? $20k?

Re:Wanted: Scala Expert

[sycodon]

Yes, it was a joke.

Re:Wanted: Scala Expert

[mattmatt]

*kick*

Eh sonny?

[fuzzyfuzzyfungus]

"Twitter has been able to sustain phenomenal growth"

This is my friend FailWhale. You are making FailWhale sad. You wouldn't like FailWhale when he is sad...

Re:Eh sonny?

[iluvcapra]

To be fair, FailWhale has not been seen by me of late, and the Twitter devs attribute their salvation to Scala. However, there are some pretty good arguments that the Twitter developers Mother of All Fail was initially trying to write their own hand-rolled message queue instead of simply using one off-the-shelf.

Type erasure

[shutdown -p now]

Scala is great, but one really annoying thing about it is that it inherits type erasure implementation of generics from Java. This means that you cannot overload methods on argument with the same generic class with different type parameters, cannot implement the same generic interface with different type parameters on the same class, cannot check whether a class implements a particular generic interface for a given type parameter, etc. They did fix some issues - for example, you can instantiate arrays - but it's still far from perfect.

I understand the need to match Java's broken model for the sake of interoperability, but surely a better way can be devised for pure Scala code? It's pretty much the only area where Scala noticeably lags behind advanced .NET-hosted languages (such as Nemerle or F#).

Re:Type erasure

[ahabswhale]

How do you propose they support this given that Java generics aren't reified? Arrays are, which is why that works.

Re:Type erasure

[pjt33]

The third of your listed limitations is semi-bogus: you can't check generic type information with instanceof, but java.lang.Class.getGenericInterfaces gives you the information you need if you're prepared to write a method to process it.

I can't help feeling that the first two can be worked around too if you're prepared to be more creative with your Miranda methods than javac.

Re:Type erasure

[shutdown -p now]

One way to reify type parameters is to make them runtime arguments. For example, let's say we want to reify java.lang.Comparable<T> such that I can write:

class Foo implements Comparable<Bar>, Comparable<Baz> {
  public int compareTo(Bar bar) { ... }
  public int compareTo(Baz baz) { ... }
}

Since interface is actually just one, on JVM level we're stuck with a single compareTo(Object); furthermore, there's no way to do instanceof checking.

For instanceof, we can just do the same thing C++ hand-coded RTTI systems did since forever: roll out our own:

interface GenericInstanceOf {
  boolean genericInstanceOf(Class clazz, Class[] args);
}

And have the compiler implement it for every class that implements any generic interface. The implementation is fairly straightforward, with a bunch of simple class equality checks, and falling back onto superclass implementation if they all fail.

Furthermore, when instanceof is used to query for a generic interface, we have to call the method instead. This part is trivial. The only question is what to do with types that implement some generic interface, but do not provide genericInstanceOf (i.e. any non-Scala type) - this could fall back to default Java behavior, or throw at runtime (probably with some additional "unsafe instanceof" operator that doesn't throw, to enable Java compatibility).

Now the methods. There isn't much we can do if the interface is defined in Java, but if it's actually a Scala trait, the corresponding Java interface can have a synthesized Class argument on all methods, corresponding to generic type parameter on the interface. Caller would have to pass the Class object corresponding to static type of expression he's calling the method on - and compiler can quietly inject it everywhere, so that user doesn't ever see it. Class implementing the interface switches on the passed type to determine the correct implementation to dispatch to.

The above looks feasible. It would obviously break Java interop to some extent, but this can be mitigated by having separate constructs to denote strict Java compatibility (so no implicit arguments, and no genericInstanceOf). Ideally, you'd mostly write in Scala, and have the best of it, and occasionally use those constructs to call to legacy Java code.

Have I missed anything?

Re:Type erasure

[pjt33]

Ah, my comment just down the page didn't take into account that you want to use the full Java standard libraries. However, it still seems to me that you're projecting deficiences of the Java language onto the Java VM to some extent. You write:

Since interface is actually just one, on JVM level we're stuck with a single compareTo(Object)

It's more complicated than that. If Foo implements Comparable then Foo.class will contain methods

public int compareTo(Bar bar) {...}
public int compareTo(Object obj) {return compareTo((Bar)bar);}

The latter is a Miranda method or synthetic method generated by the compiler. There's nothing to stop the Scala compiler from making synthetic methods along the lines of

public int compareTo(Object obj) {
  if (obj instanceof Bar) return compareTo((Bar)obj;
  return compareTo((Baz)obj);
}

The main complication here would be that you still couldn't have

Foo implements Comparable<Bar<String>>, Comparable<Bar<Integer>>

This probably would be doable with a custom classloader which automatically injected either synthetic methods with different names or synthetic methods with an extra java.lang.reflect.Type argument. Or if you really want to get ugly you could have a small Scala runtime which used ThreadLocal to pass the extra arguments along without changing the actual method signatures.

Re:Type erasure

[shutdown -p now]

The limitations are all bogus; the point is that it should be Scala compiler that's doing all the jumping through hoops, and without telling me, too. I should just be able to write code in a straightforward way, same as I can on .NET (where it's the VM itself that's doing all the dirty work).

Re:Type erasure

[shutdown -p now]

First, overloads are convenient. There's a reason why method overloading is in the language.

Second, this wasn't about overloading at all! This was about implementing the same generic interface more than once on a single class, providing different implementations for different generic type parameters. Overloading is merely an artifact of that - since Java does not allow one to rename implementing methods as C# does, overloading is unavoidable in this case, since method name is the same in all cases, as defined by interface being implemented.

Re:Type erasure

[mwildam]

I am beginning to get tired of messages that Java is underdeveloped or "broken" (as you say). In all the newer languages I cannot see THE reason for using it. And I started only about a year ago to really use Java. I think there is still a long way until the killer language is born and matured. I totally agree with the folks that think 10 times before implementing a new language feature into Java.

At least with the programming language I don't want to have already the same issues as with big software products that have a lot of features packed into them but are awful to use (in performance and usability).

Re:Type erasure

[puppetluva]

This isn't true at all. Scala's genetics are far more powerful than java's type erasures except in the case where you have to inherit/use an existing java class.

Odersky actually created g4j for sun before writing scala. It stands for "generics for java" and it didn't use erasure there either. Sun scrapped it for type erasure and odersky left and created scala.

Re:Type erasure

[DuckDodgers]

Your experience with Java is hugely different than mine, then. In no particular order, these features of Java irritate me:

- Embedding a large String in a source file. I shouldn't have to use a named String in an XML file every time I want a String more than 60 characters long. Scala (for example) allows triple-quoted Strings, starting and ending with """, so I can do
"""select user.first_name || user.last_name as "full_name"
from user where id = 2983573;"""
And that will compile just fine. Now obviously, if I have huge SQL queries or other fragments, using a separate properties or XML file makes sense.

-Information passing. Our code is littered with Java classes like this:
class TransactionData { private Date date; private Long transactionId; public Date getDate() { return this.date } public Long getTransactionId () { return transactionId; } public void setDate(Date date) { this.date = date; } public void setTransactionId(Long transactionId) { this.transactionId = transactionId; } }
In some cases, especially with lots of different data in one place, those Java objects make sense. But in many cases, it's a useless data holder class created for the sole purpose of passing information back and forth between two different Java classes. Now, you could use an Object array to do the same thing - but then you have to cast everything to the appropriate type when you pull it out of the array. Scala Tuples solve this problem, and would eliminate literally thousands of lines of code from our codebase. Scala also has a shortcut for class definitions that automatically generates getters and setters for you, and lets you easily override the defaults if you need non-standard getter or setter code.

-Null checks. Our Java code is just full of code like this:
SomeType x; SomeOtherType y; SomeThirdType z; x = doSomeCalculation(); if (x != null) { y = x.getY(); if (y != null) { z = y.getZ(); } /* else log some error about not finding y */ } /* else log some error about not finding x */ if (z != null) { doSomethingWithZ(z); } /* else log an error about not finding z */
Scala has Options which shortcut the whole procedure and let you write the exact same logic in a much simpler way.

-Inheritance. We have a number of interfaces and abstract parent classes that are used left and right in the Java code. Every time a method changes in one of the interfaces, we have to re-write the class hierarchy or insert an intermediate parent class. The "Java Design Patterns" solution is to use the Strategy Design Pattern and compose simple implementations of the interfaces with the classes. It works, but it results in lots of code. Enter Scala traits, which are an interface WITH its implementation. Each Scala class can be composed with a trait by adding the trait name to the class declaration. *Poof*, you get your Strategy Design Pattern in far fewer lines of code. (Scala traits give Java multiple inheritance without the multiple inheritance headaches of C++.)

-Cases. Java has a nice switch construct... for numbers. Most of our comparisons in web code is with Strings, so instead of nice, easy to read switch (variable) { ... } in our code, we have tons of if (variable.equals("...") else if (variable.equals("....") ....)
Scala gives you a case statement that's tremendously flexible, and can handle Strings, Exceptions, Lists, it doesn't matter. You can't believe how much this simplifies your code until you see it in action.

-Exceptions. In Java, you have to explicitly catch all of your checked exceptions or declare them to be thrown. In Scala, all exceptions are unchecked. You only put the "try / catch" blocks where you want them to exist, and you don't have to do "throws this, that, theotherthing, andsoforth, andsoon" on your method signatures.

-XML. Java uses XML like crazy, and the APIs for reading and writing it are

Re:Type erasure

[mwildam]

Your experience with Java is hugely different than mine, then.

I have clearly not so much experience as you, but I am a Software Developer since being a school boy so my experience is about 25 years using more than 10 different languages (and I admit I am also a little tired of learning new ones every few years).

- Embedding a large String in a source file.

Large strings I do usually read from external templates (not necessarily XML which I find ugly and inefficient for most cases). Although the """ is a nice feature it is IMHO no major benefit.

-Information passing. Our code is littered with Java classes like this:
class TransactionData { private Date date; private Long transactionId; public Date getDate() { return this.date }
[...]

Object oriented programming can also be exaggerated... - Although Java is an object oriented language not everything must be necessarily packed into it's own class. I only have few such boilerplate code because if I have too many too similar classes I do combine them or make one parent class. For years I developed in VB where neither inheritance exists, but I learned from this, that in many cases re-combining existing classes is a very useful option.

But in many cases, it's a useless data holder class created for the sole purpose of passing information back and forth between two different Java classes.

Then maybe a different way of passing data around would be a good idea - but that said, I know that in most projects there is a large stack of frameworks used like Hibernate, Spring and the like. Once tripped in there, it's hard to get out and forces you to that coding style.

-Null checks. Our Java code is just full of code like this:
SomeType x; SomeOtherType y; SomeThirdType z; x = doSomeCalculation(); if (x != null) { y = x.getY(); if (y != null) { z = y.getZ(); }

Yep, that one I really know also - I didn't think of this so far because I wouldn't have expected a solution for that. ;-)

Scala has Options which shortcut the whole procedure and let you write the exact same logic in a much simpler way.

One concern that I have in general when the discussion comes up of writing something in a shorter way is readability. I remember some famous "one-liners" from C++-Programmers that nobody could understand. I know developers who forget very fast of what and why they did...

-Inheritance. We have a number of interfaces and abstract parent classes that are used left and right in the Java code. Every time a method changes in one of the interfaces,
we have to re-write the class hierarchy or insert an intermediate parent class.

I think I did not get exactly what you mean here. But I remember times where refactoring was very hard manual work. Maybe from those times I do think 10 times when designing interfaces before I start with the implementation.

Scala traits give Java multiple inheritance without the multiple inheritance headaches of C++.)

Not everything that can be done should be done. Since working with Java I consider the restriction to single inheritance as a good idea. Although I do most projects alone, I have seen enough foreign code that drove me crazy.

-Cases. Java has a nice switch construct... for numbers.

Yep, I know this one and I argued about that. - But it should come with Java 7 ASFAIK.

-Exceptions. In Java, you have to explicitly catch all of your checked exceptions or declare them to be thrown. In Scala, all exceptions are unchecked.

I really like to have the option to use checked exceptions! And you can also use unchecked exceptions if you like - and guess what: you neither need one of those you can also live without them (at least in your application,

Re:Type erasure

[shutdown -p now]

I am beginning to get tired of messages that Java is underdeveloped or "broken" (as you say).

You shouldn't read in my words what isn't there. I didn't say that Java is broken. I've only said that Java generics are broken - an opinion that is shared by many Java experts, and, to the best of my knowledge, the majority of people that have anything to do with PL design. Google for "Java generics broken", and see for yourself.

Re:Type erasure

[shutdown -p now]

Do you have any references for your claim that Scala generics aren't implemented via type erasure? Because I have provided some links discussing that in the post you've replied to, and they agree with my point of view (that type erasure is there).

Actually, let me just use the primary source. See Scala Language Reference, 3.7 "Type Erasure", and all references to it in the same document. In particular:

Example 8.3.2
Consider the program fragment:

val x: Any
x match {
case y: List[String] => ...
}

Scala does not maintain information about type arguments at run-time, so there is no way to check that x is a list of strings. Instead, the Scala compiler will erase (paragraph 3.7) the pattern to List[_]; that is, it will only test whether the top-level runtime-class of the value x conforms to List, and the pattern match will succeed if it does. This might lead to a class cast exception later on, in the case where the list x contains elements other than strings. The Scala compiler will flag this potential loss of type safety with an "unchecked" warning message.

Re:Type erasure

[mwildam]

Sorry, I overlooked that you were talking of generics only. I searched Google as you proposed.

The first link that comes up (http://davidrupp.blogspot.com/2008/01/java-generics-broken-we-report-you.html) has in the comments the correction - I think it was intended that way (see comments).

The link http://hinchcliffe.org/archive/2005/01/07/146.aspx talks about Java as well as C# generics "broken".

Reading through a few examples I think I would never have noticed those problems without having such examples given. The "? extends Something" seems complex but I think I understood why they intended it that way. Generics are a "tool" for you to explicitly specify needed classes (for whatever reason).

Re:Type erasure

[shutdown -p now]

Okay, let me be even more specific.

I do not consider wildcards (which are just use-site variance declarations) broken. They are complicated, yes, and the presence of declaration-site variance declarations, as in Scala or C# 4.0, would alleviate a lot of need for them, but they are necessary to deal with generics properly (and in that sense, the lack of any means to specify usage-site contravariance of generic type parameter in C# is what's "broken" there).

I do not find constrained generics (as opposed to unconstrained C++ templates) broken, either - it's quite obviously an issue of type safety.

The problem with Java generics is solely type erasure. The point is that a generic class or interface should represent a distinct type for every distinct set of type parameters. It works that way in C#, so I can write, for example:

class Foo : IComparable<Bar>, IComparable<Baz> {
...
}

If my class Foo is indeed comparable to both Bar and Baz. Furthermore, I can test for presence of such interfaces at runtime:

if (foo is IComparable<Bar>) { ... }
else if (foo is IComparable<Baz>) { ... }

or overload methods:

void Foo(IComparable<Bar> x) { ... }
void Foo(IComparable<Baz> x) { ... }

In Java, this doesn't work, because due to erasure of generic type, there's just a single interface Comparable, which cannot be implemented twice. For the same reason, you cannot overload a method, when the only difference is in the type parameters. This is a very artificial limitation, and it is a practical one in a sense that it results in some very meaningful type hierarchies being non-representable in Java (there's a question about this every now and then on Stack Overflow).

Re:Type erasure

[badkarmadayaccount]

In order:

• Strings -valid complaint here, nothing to say.
• Information passing - Java support templates,IIRC, for that object array,and if templates don't solve the casting problem, subclass core types extending them with appropriate get() and set() methods, and box the variables.
• Null checks - See above.
• Inheritance. Java has an Aspect oriented extension, if not several. and if combined with interfaces give you a simplified form of multiple inheritance, which is what you are looking for.
• Cases. Isn't polymorphism a key trait of OOP? Can't you implement an int interface for those data types, possibly on top of templates?
• If I understand Java philosophy, everything is an object, can't you make a namespace wide override of the exception class to suit your needs? If not, then it is a valid complaint.
• XML. Isn't that supposed to be a function of the preprocessor?

Re:Type erasure

[puppetluva]

I'm so glad you are on slashdot -- you were right, and I was wrong. Ego aside, it may actually not matter because Scala manages to avoid the problems of erasure in java.

The discussion here discusses the issue and talks about how the perils of type erasure of Java don't have the same negative effects in Scala:

http://lamp.epfl.ch/~emir/bqbase/2006/10/16/erasure.html

Thanks for demanding precision in the discussion.

oblig

[Anonymous Coward]

Different tools for different jobs.
That being said, does anyone know of a good comparison of languages broken down by what they're best at doing? How does one decide what the best language for what they want to do is? My google-fu is weak today. I found this: popular programming languages; but the analysis seems lacking.

Re:oblig

[d'fim]

"C++ for everything. All the other languages start off with it after all."

Examples: Fortran, Lisp, C.....

Re:Reinventing the wheel is sometimes good

[hey]

Like mod_perl ?

Re:Reinventing the wheel is sometimes good

[Fnord]

You mean like Mason? Possibly you're looking for something more like Catalyst?

These things have been available for Perl for a long time.

Re:Miracle language.

[Doctor O]

maybe it will make my hair grow back

OTOH, it might as well make your back hair grow, and who wants that?

Re:Strongly typed language?

[Tom9729]

http://www.google.com/search?q=strongly+typed+language

Re:Strongly typed language?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Strongly_typed

Re:Strongly typed language?

[Ann Coulter]

Strongly typed languages usually make type conversions explicit and enforce type restrictions; whereas weakly typed languages usually allow implicit type conversions and relax type restrictions.

Explicit type conversions disallow a value of type T to be treated as a value of type S without invoking a function that takes a value of type T and returns a corresponding value of type S. For example, a conversion from an integer type to a floating point type requires the invocation of a function that performs the conversion. Contrast this with implicit type conversions where a value can be treated as almost any type depending on how it is to be used.

Type restrictions only allow certain operations to be done to certain types. For example, numerical addition mïay only be performed on numerical types. A lack of type restrictions allow for numerical addition to apply for, say, booleans, for example.

Re:Reinventing the wheel is sometimes good

[Coryoth]

But if all you're doing is reinventing Perl with C-like syntax, it's not really a step forward.

Perl already has C-like syntax. It doesn't, however, have static type checking, let alone robust static type checking (with nice features like variance annotation etc.); nor does it have particularly robust functional programming support -- you can certainly do functional programming in Perl, but it isn't as clean and syntactically sugared as it could be; nor does perl have particularly clean OO if we're being honest -- yes it works and can be made to work quite well, but elegant isn't a word that comes to mind when I think Perl and OO; nor does Perl have function pattern matching and algebraic data types; nor does Perl have a nice concurrent programming interface based on the Actor model. None of this is really to say that Perl is bad -- it is very good for a great many things, and the features I've mentioned needn't hold it back. My point is that Scala is most certainly not re-inventing Perl. In fact Scala doesn't even have a particularly C-like syntax: it's less C-like than Perl really.

Got me into functional programming

[DollyTheSheep]

Back at university I somehow dodged functional programming. I knew functional programming was and is an important concept, but besides an excursion to Prolog and some SQL I never went outside imperative and/or object-oriented programming. I never wanted to learn Lisp or Scheme, Haskell seemed to much for mathematicians back then. Scala intrigued me enough to give functional programming a try again. It's object-oriented, has generics, is strongly typed, but has a powerful inference systems, so declaring things is not too tedious. Java classes and packages can be used within. It has not only builtins for concurrency but also for parallelism. However, it was the functional programming paradigm opened my eyes, what I was missing yet.

Re:Miracle language.

[spun]

... Twitter has been able to sustain phenomenal growth, and it seems with more stability than what they had before the switch, so I think that's a good testament to Scala...Hmmmm, maybe I should switch my company's programming language to Scalia. After all, it cause market share to increase, computer systems to become more stable, and maybe it will make my hair grow back. I'm in!

No, this is Scala, a language that is a blend of functional and object oriented programming. Scalia is mix of textualism and originalism with a very conservative framework. Some consider its inability to recuse itself to be its greatest asset.

Re:Strongly typed language?

[xgr3gx]

Ah - duh. Immediately started thinking typed, as in the clicky clicky kind of typing done on a keyboard.
Man, was that a loud and smelly brain fart.
Thanks for that.
Sorry. Sorry Everyone!

Software Engineering Radio...

[tcopeland]

...had Martin Odersky in for an interview a while back.

It's good stuff; se-radio isn't afraid to get down in the weeds with the interviewee.

Re:Strongly typed language?

[Ephemeriis]

What does that even mean?

It basically means that variable types are rigidly enforced and conversions are explicit.

It's annoying, but also eliminates some possible mistakes.

For example, say you've got a float variable: FloatNum1
And a couple integer variables: IntNum1, IntNum2

Some languages don't care much about variable types and do conversions on the fly. So you could write code to do
IntNum2 = (FloatNum1 + IntNum1)
and nobody would complain. No errors. Nothing. It would compile and run just fine. At least, assuming you didn't lose something important in a rounding error somewhere.

A strongly typed language will not allow that. It will kick out errors, refuse to compile, and generally pitch a fit. You are not allowed to add a float to an integer, and you certainly aren't allowed to assign it to another integer variable. Instead, you do something like this:
IntNum2 = (Float_to_Int(FloatNum1) + IntNum1)

Library vs core language

[Anonymous Coward]

FTA: actors in Scala are not a language feature, they have been done purely as a Scala library

So:
1. There will be no useful compiler warnings/errors for the feature, since compilers implement only the core languuage.
2. Even if the library code will be 100% bug free, you'll still have to drag a debugger though it when debugging a hard bug in nearby code.
3. The library's API will never acheive the self-consistency of the core language because of too many cooks spoiling the broth.
4. The library will be massively overfeatured, but still not do what you actually want.
5. The library will change more frequently than core langage, meaning nothing will compile in the real world without hacks.
6. The library designer will hypnotise the core language designer and impose his own stupid ideas on the core language.
7. (6.) will lead to the entropy death of the language; people will simply stop paying attention to new versions.

Seriously, we should be figuring out a minimal subset of concurrancy features that really *can* go into a core language, with compiler support, debugger support, good consistency (like the while loop which does the same thing in all languages) etc.

Then libraries can implement endless semantic sugar/bullet-point fluff on top of the core features, since that's what libraries are good at.

Re:Library vs core language

[Homburg]

All of your points are bullshit, but especially:

1. There will be no useful compiler warnings/errors for the feature, since compilers implement only the core languuage.

There's no reason that a library can't express sufficient semantics for the compiler to detect errors with its use.

Re:Library vs core language

[Razalhague]

FUD

Re:Strongly typed language?

[Dgtl_ _Phoenix]

Assuming you're not being merely rhetorical (because the definition is kind of loose), strongly typed just means that the language makes some restrictions on how operations operating on different value types can be intermixed. Assuming that you're not a programmer, I'll give an example. Letâ(TM)s say you have a BMW Z4 roadster. It's a car. Understanding the nature of cars, you know that it can be classified as a vehicle, a sports car, a BMW sports car, and a BMW Z4 roadster. Strongly type languages make restrictions like you can't just say: roadsterCar car = myCar. This is implicitly is saying my car is roadster. Rather you have to explicitly say that the car is a roadster (called a cast) like this: roadsterCar car = (roadsterCar) myCar This concept has a number of benefits, most of which are related to catching programming mistakes before they become bugs or immediately at runtime. Without strongly typed languages, you won't notice that you tried to call a bike a BMW Z4 roadster until you try to get it up to 140 miles an hour. And by then you might have tried to do valid but nonsensical things that might have really broken something.

Scala is a joy...

[sitarlo]

Probably the most robust JVM compatible language to date. Even the creater of Groovy digs Scala: http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html

Twitter - testament to Scala - Really?

[Anonymous Coward]

"Twitter has been able to sustain phenomenal growth, and it seems with more stability than what they had before the switch, so I think that's a good testament to Scala"

Have you ever bothered to look what the Twitter site does - there is virtually nothing to it. To argue that any language that is behind it is a testament to that language is ridiculous. The bigger question is how could they get any language to unstable for such a trivial set of functionality?

Re:Twitter - testament to Scala - Really?

[Ichoran]

A very high volume of triviality is non-trivial.

Re:Twitter - testament to Scala - Really?

[Anonymous Brave Guy]

And when the going got tough, as I recall, Twitter fell over, as did most of the other darlings of the current social networking hypewave.

It's kind of amusing that people have started to think of simple web front ends to simple CRUD applications as if they're demanding. Indexing the entire WWW is demanding. Running the financial systems behind a bank is demanding. Modelling weather systems is demanding. The CAD models for a 60' yacht are demanding.

Running a web site that provides a trivial front-end to a database with one three-column table is not demanding, even if you're getting lots of hits. And it still fell over.

Doomed

[decipher_saint]

Martin Odersky is beardless, Scala is doomed.

Re:Doomed

[Adm.Wiggin]

Finally, the comment I was looking for, since I was too lazy to look up his picture.

For the curious: http://www.alenz.org/mirror/khason/why-microsoft-can-blow-off-with-c.html
And the followup: http://khason.net/blog/computer-languages-and-facial-hair-%E2%80%93-take-two/

MVC framework

[Godskitchen]

Scala on Scales?

Re:MVC framework

[murderswitch101]

Scala on Scabies

Not sold on Scala

[glwtta]

Am I the only one not terribly enamored with Scala? It's a massive language (have you seen the book?), but a lot of the syntax is somewhat redundant and doesn't seem to add that much. The type system is downright byzantine, and the Java interface is, let's say, somewhat inelegant. And the whole object-functional thing seems like a paradigm in search of an audience (maybe I'm just not getting it).

And you get to pay for all this with a huge performance hit.

I guess their "more is more" approach is mostly making Clojure look more attractive.

Re:Not sold on Scala

[shutdown -p now]

Am I the only one not terribly enamored with Scala? It's a massive language (have you seen the book?), but a lot of the syntax is somewhat redundant and doesn't seem to add that much. The type system is downright byzantine, and the Java interface is, let's say, somewhat inelegant.

I've read the book. Yes, it's fairly complicated, but then all languages tend to become that as they move from academia or design-by-committee stage into real world - witness Java. In terms of power, however, it's one of the most advanced languages today which can be used in production... and yet it's statically typed, which is a plus in my book.

And the whole object-functional thing seems like a paradigm in search of an audience (maybe I'm just not getting it).

You probably aren't. It's been a big thing in .NET land ever since C# 3.0 appeared, and grows even bigger now with F#. It's a pragmatic approach - it gives you both OO and FP tools, and lets you mix and match freely to get the optimal balance for the task at hand.

And you get to pay for all this with a huge performance hit.

I guess their "more is more" approach is mostly making Clojure look more attractive.

Funny how you speak about performance hit, and then immediately mention Clojure...

Anyway, where did you see the "huge" perf hit there? Examples? It's still JVM bytecode, remember, and it's statically typed, so in the end it's mostly normal Java method invocations all around. It has to fall back on reflection for some things that JVM simply doesn't support otherwise, but those are corner cases, not normal operation.

Re:Not sold on Scala

[JAlexoi]

whole object-functional thing seems like a paradigm in search of an audience

Ah, young grasshopper. You are not aware of the mixed paradigm programming languages then. See OCaml, that is object/function oriented lang.

And you get to pay for all this with a huge performance hit.

That is definitely an overstatement. The performance hit is not huge, it's not even big.

Now, if you want a language with truely different syntax, try erlang.

Re:Not sold on Scala

[zuperduperman]

> And you get to pay for all this with a huge performance hit.

Are you sure about that? As in, actual benchmarks sure?

One of the reasons I find Scala very interesting is that it produces byte code which, in many cases, is identical to what raw Java produces. If Scala invokes a Java method, the byte code just calls it directly. Unlike Groovy where there are about 20 layers on the stack between each call.

From my rather trivial benchmarks, Scala seems only marginally slower than raw Java code. That is pretty amazing given that java itself is these days considered one of the best performing languages available.

Re:Not sold on Scala

[glwtta]

Yes, it's fairly complicated, but then all languages tend to become that as they move from academia or design-by-committee stage into real world - witness Java.

Java is an extremely simple language; it has a large library and a lot of auxiliary APIs - which do often tend toward overnegineering - but the language syntax is quite a bit simpler than Scala. It's an important distinction, ignoring libraries you don't need takes a lot less effort than language features you don't need.

And yes, I do tend to like statically typed languages as well.

You probably aren't. It's been a big thing in .NET land ever since C# 3.0 appeared, and grows even bigger now with F#. It's a pragmatic approach - it gives you both OO and FP tools, and lets you mix and match freely to get the optimal balance for the task at hand.

I understand the concept, I'm just not sold on The Scala Way in practice (hey, just a personal opinion). Actually, the C# way seems like a much quicker win - I would love to have a subset of Scala's functional features in Java (certainly would make adoption easier).

Funny how you speak about performance hit, and then immediately mention Clojure... Anyway, where did you see the "huge" perf hit there? Examples?

Fair enough, "huge" is an overstatement, let's go with "significant". The best performance data I could find was this - it does show that you will run into at least a few cases where the compiler is being quite dumb - good benchmarks are hard to come by, though. And yes, Clojure has the same problem, but hard data is even sparser for Clojure.

Re:Not sold on Scala

[Ichoran]

The best performance data I could find was this - it does show that you will run into at least a few cases where the compiler is being quite dumb.

Actually, that's the coder, not the compiler. The worst cases there were for code that was apparently not written with performance in mind at all. From what I saw, there was only one "gotcha" that arguably was the compiler or JVM's fault having to do with lack of optimization in certain types of static initializer code, and even then it only came up because the coder tried to save a dozen or so characters in the code.

Re:Not sold on Scala

[TheNarrator]

I just finished reading Programming In Scala. Yes, it's a big language. There is a lot going on for sure. Extractors, Case Classes, Pattern Matching, Implicit Functions, just to name a few. Reading about scala can be a bit overwhelming. I had to really get my hands dirty with a small project before I really was able to understand and appreciate all the features and how they work together. The fun thing about Scala though is that one can start out programming in a Java style and slowly incorporate its more advanced features. While working on a toy web app in the excellent Lift web framework, I found that as I applied Scala features my code kept getting smaller and smaller. It was kind of fun to see how small I could get it as I piled on more language features. I actually found myself quite amused at the power of the language.

Re:Not sold on Scala

[sciencewhiz]

whole object-functional thing seems like a paradigm in search of an audience

Ah, young grasshopper. You are not aware of the mixed paradigm programming languages then. See OCaml, that is object/function oriented lang.

I don't think you answered the GP's question. An example of the paradigm doesn't show that there is an audience. To answer the question would show that there is a class of (real-world) problems that an object-functional language solves better then anything else, or even better to give examples of businesses or major projects that are using an object-functional language. The Wikipedia page for OCaml doesn't give me much confidence that there is an audience for it.

Re:Reinventing the wheel is sometimes good

[SL Baur]

My point is that Scala is most certainly not re-inventing Perl.

True, it also doesn't appear to be a reimplementation of anything. It's somewhat related to Java (Scala programs execute with the JVM).

The code snippets on the website http://www.scala-lang.org/ are intriguing. It's certainly a terse language. That's both good and bad.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Strongly typed language?

[SL Baur]

Scala is statically typed. Most languages are strongly typed so that's not a particularly useful metric.

Static typing means that every object type is known at compile time and thus type safeness can be enforced before the code is executed.

Re:Strongly typed language?

[maxwell demon]

The ultimate answer to your question (sort of)

Choosing a language

[jma05]

I could use an alternative programming language for the JVM that is more expressive than Java. Both Scala and Groovy integrate well with Java at the language level, albeit with different type systems. While I do use Groovy from time to time, what kept me from Scala was that it is not well supported by IDEs (Eclipse/Netbeans - I hear things are somewhat better with IntelliJ). The problem is the nature of Java libraries. They tend to be deeply nested and often expressed in lower level abstractions and are difficult to use without strong IDE support. I don't need an IDE for Python (flat module systems, high level libraries), but certainly do for Java. With solid IDE support however, I am nearly as productive in Eclipse + Java as with dynamic languages, even for medium apps. Scala and Groovy come with their own standard libraries and I don't need IDE support as long as I stay within them. But sooner or later, I will need to step into plain Java land and I no longer feel productive. I would rather use straight Java for them.

The development experience is language + tools, not just the language. While Scala can piggy back on JVM and undercut the rest of the process that languages need to go through to mature and be accepted, Scala plugin (or someone else) has to provide a JDT equivalent first to have popular appeal.

I just wish there was a well supported superset of Java with productivity considerations that maintains 1:1 byte-code compatibility on compilation. Java purists can keep their language clean. But the rest of us can be happy too. Scala has that potential.... almost. So far, Groovy has been filling that role for me. Groovy will never have the kind of edit-time IDE intelligence simply due to it's dynamic nature. But for now, it stands ahead (after all, it has been around longer).

Re:Choosing a language

[slartibart]

I like Groovy, it's java-like and scratches some of my biggest itches about java.

However I like Clojure better. It's hard for me to resist the power of a lisp, with a full macro system, *and* full java interop. To me it's the only JVM language that stands out, Scala and Groovy are nice, but I don't see why they are any better or different than JRuby or Jython.

Re:Choosing a language

[ahabswhale]

Groovy is different because it's easy for Java programmers to learn. In fact, most Java devs can understand Groovy code with little or no explanation. That's certainly not the case for JRuby or Jython.

In any event, I agree Clojure is pretty sweet. However, being a Lisp, it's future is questionable. A lot of devs won't be willing to deal with the brain melting process necessary to grock it.

Re:Choosing a language

[slartibart]

Groovy is different because it's easy for Java programmers to learn. In fact, most Java devs can understand Groovy code with little or no explanation. That's certainly not the case for JRuby or Jython. In any event, I agree Clojure is pretty sweet. However, being a Lisp, it's future is questionable. A lot of devs won't be willing to deal with the brain melting process necessary to grock it.

Yeah I agree with you there. I do use groovy as my "java and then some" language. It looks an awful lot like ruby to me, but yes it's more java-like.

Its unfortunate about lisp(s) and their popularily, because honestly I don't see what's so difficult about them. Macros are hard, but lisps don't force you to use them. Other languages don't even give you an option, you can't. Paren matching is done by any modern editor. Prefix notation is a bit unintuitive I guess, but that slowed me down for maybe a couple of weeks, about the same as new syntax for almost any language. I am starting to think that "a lot of devs" just don't want to understand it. Or maybe a lot of devs just don't get programming in general, they just learn their one language, and can maybe pick up a few similar ones.

Re:Choosing a language

[Ichoran]

I've found NetBeans + Java + Scala to not detract at all from NetBeans + Java. So to me, it's a win to add Scala to the mix. It would also be a win to add Groovy or Clojure or Jython or whatever; I just find adding Scala to be the biggest win because the interoperability with Java is easiest (at least in the Java->Scala direction) and because performance is by far the best.

Re:Choosing a language

[Ichoran]

Scala is better and different from Groovy and JRuby and Jython in that it is statically typed (but does a fantastic job at hiding all the type nonsense as long as you are doing something sensible). Those of us who make type errors as one of their most common errors really benefit from this. It is also better and different in that it is quite a lot faster than the interpreted languages. (It is worse and different in that a few fancy tricks are impossible, such as method-missing stuff, or generic operations using anything for which the operator is defined, etc..)

Re:Choosing a language

[rombertw]

. Groovy will never have the kind of edit-time IDE intelligence simply due to it's dynamic nature. But for now, it stands ahead (after all, it has been around longer).

The SpringSource guys seems to hold a different opinion: http://blog.springsource.com/2009/07/30/a-groovier-eclipse-experience/ . They're doing some pretty neat stuff with Groovy in Eclipse.

Re:Choosing a language

[jma05]

I should have mentioned that I did try Clojure. While it is certainly the epitome of dynamic typing and syntactic flexibility for the JVM, I rejected it for the same reasons (no code completion and other validations). Most of the software I choose to write in Java is so because of the specific libraries. Most of code ends up manipulating these libraries, not as my custom logic. If I had a lot of custom logic, I could see value in Clojure (or in Scala as I mentioned in my previous post) where I could use it for domain specific code and keep the low level, object oriented API interaction to a minimum through a few wrappers written in Java. Unfortunately, those are not the kind of applications I write these days.

My point is the same... that these may be great languages but will remain incomplete in their offerings as long as their designers/community don't take the IDE as seriously as the language design. It is fortunately not as hard as it once used to be to bridge that gap, given that Eclipse and other IDE platforms already provide much tooling. Perhaps in a few years when IDE ecosystem further matures, languages can be considered on their own merit and not based on the baggage they now carry.

Re:Choosing a language

[zuperduperman]

> Scala and Groovy are nice, but I don't see why they are any better or different than JRuby or Jython.

Each one has it's own special advantages.

Scala - it's the only one that has kept static typing. While many people have turned against static typing, I think vast businesses with huge software will be much slower to let go of it. As a direct result of the static typing, Scala's performance is much much better for many use cases, and it also offers the possibility of keeping all the power of the refactoring tools Java programmers are used to in their IDEs.

Groovy - unlike JRuby or Jython, Groovy integrates with Java 100%. While the others can certainly use java classes and invoke java libraries, once you get to more complex integration or fringe areas they often break down. For example, unlike Groovy you can't define all the kinds of annotations in Jython that you can in Java. That might sound like a niche use case until you realize that all the modern Java libraries such as EJB, Hibernate, Stripes and many others are building heavily on these annotations and they just won't work without them.

Personally, I hope that Scala gets adoption because I think static typing has never really had a fair go on the JVM with a truly popular language using type inference to make it convenient. On the other hand, Scala is not ready yet, so for the time being, Groovy is doing it for me.

Re:Choosing a language

[JSlope]

You should try IntelliJ IDEA, they have a free trial, from my experience it seems that there is easy access to libraries from scala code.

Re:Choosing a language

[Anonymous Coward]

Parent suggested:

y = [x*x for x in list]
vs
(let ((y (map (lamba (x) x*x) list)))

Personally I prefer a syntax like

y = list.map (function (x) x * x);

where the BNF for a lambda should be something like

lambda-expression := FUNCTION '(' params-list ')' statement
| FUNCTION ':' return-type '(' params-list ')' statement ;

so you could even write

square = function : int (x:int) { return x * x; };
y = list.map(square);

if you don't feel like trusting the compiler's ability to do type inference.

Re:Choosing a language

[bar-agent]

The problem isn't that lisp is hard to understand conceptually, it's that it's hard to read and write. Lisp code just doesn't look nice. The syntax in other languages gives a set of visual cues to what's going on in a program.

This is very true. My language of choice is Dylan, which has much of the power of Lisp or Scheme, but uses a much more readable ALGOL-family syntax. It actually came out around the same time as Java did, but Java had a metric ass-ton of money poured into advertising, and Dylan didn't. Apple screwed that up.

y = [x*x for x in list]

The Dylan equivalent would be
let y = map(rcurry(\^, 2), list)
or
let y = map(method (x) x*x end, list)

Re:Choosing a language

[rodrigo1979]

Check out the Fan language at fandev.org Some of the features you mentioned I think are covered in Fan. http://www.fandev.org/doc/docIntro/WhyFan.html

Re:Choosing a language

[badkarmadayaccount]

Dude, I'm a 15 y.o. who's written less C in his lifetime than most /.ers in a day, and even I "get" Lisp, though I'm too lazy to write any. Then again, I'm in to weed, so that may explain some things...

Re:Choosing a language

[ahabswhale]

In this case, your age is an advantage. If you've been coding for 15 years in a certain way and then have to learn how to do it in an entirely different way, it's significantly more difficult. Not impossible, of course, but difficult enough that most won't bother if they can get away with it.

Re:Strongly typed language?

[John Betonschaar]

Funny that you picked this particular example, because even strongly typed languages more often than not allow implicit floatint conversions. Take C/C++ for example, which would be a prime example of a strongly typed language but still it allows implicit int->float conversions, and many compilers don't mind going from int->float conversions either, even though it's a narrowing type conversion.

A better example would be something like string s = '0nice' and int i = 1. A typical weakly typed language allows statements such as string t = s + i (yielding '0nice1' for example) or i = i + s (multiple possible interpretations possible, but most languages would convert '0nice' to 0 to get i = i + 0).

Re:how impressive is the twitter implementation

[maxume]

I have no idea how hard is should be, but remember, each time Scoble farts, twitter has to handle 93,000 messages.

Re:how impressive is the twitter implementation

[natehoy]

Given the number of reported "fail whale" incidents (if I'm naming them correctly), apparently it's really, REALLY hard to do. Or at least for the people who did it...

Bit I'm not a Twitter-er. I have an account and I occasionally read news blurbs on it, but I have yet to post anything on it.

Re:Reinventing the wheel is sometimes good

[moon3]

already has C-like syntax

Why not use the C instead then, or even better C++. After all many top websites run C++ (Google,eBay,Yahoo) as it is the fastest, well memory utilizing, best threading performance and green/CPU saving solution. With the native processor exceptions used properly it is also the most robust solution.

Re:Strongly typed language?

[shutdown -p now]

It basically means that variable types are rigidly enforced and conversions are explicit.

Actually, no, it means that value types are strongly enforced. A language may not have typed variables at all, and still be strongly typed - Python and Ruby are both examples of that. Static/dynamic typing, which is what you describe, is orthogonal to weak/strong typing.

Examples of weakly typed language are PHP, Tcl, and AFAIK Perl.

Re:Strongly typed language?

[Anonymous Coward]

"To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard." --Peter van der Linden, Expert C Programming.

OO + Functional = CLOS

[helixcode123]

Umm... I think we were doing this a long time ago in Lisp with CLOS (and flavors).

Re:OO + Functional = CLOS

[maxwell demon]

(Yes (but ((many people) (do (not like)) (so (many) parentheses)) in (their code)))

Re:OO + Functional = CLOS

[azgard]

They are free to write a reader macro.

Re:OO + Functional = CLOS

[Haeleth]

I find it slightly amusing that people object to Lisp on the grounds of "too many parentheses".

((Java<tends<to,have>>)quite()).a(lot()).of(punctuation()).too();

Re:OO + Functional = CLOS

[chthonicdaemon]

f1(a, b, f2(d, e)) has the same number of parentheses as (f1 a b (f2 d e)), they're just in different places.

Re:Oooooooohhhh....

[seizurebattlerobot]

Sounds like someone is bitter about not having much choice in their life. You probably don't have any hobbies, either, since your employer wouldn't approve. Have fun tilling the land for your lord. The rest of us will be making real money for ourselves, out-competing your boss because of productivity gains from using decent tools, as opposed to whatever tools your boss thinks are the cheapest to teach monkeys to use.

Enjoy your job. Maybe if you're a good, your employer will give you a 1% raise next year? As long as it doesn't cut into executive bonuses, that is.

Re:Strongly typed language?

[Abcd1234]

What does that even mean?

It means you're not qualified to even enter this discussion. Go take a course on programming languages and then get back to us.

Re:Oooooooohhhh....

[david_thornley]

Next biggest thing for the "guys with a job" crowd.

Learn some other language that isn't C#, Java, C++, VB.NET, or in fact particularly related.

Specifically, learn something with functional programming, or a different sort of object orientation (Common Lisp comes to mind, or Smalltalk or Objective-C), or declarative programming (like Prolog)...anything that's considerably different from any of the standard compiled OO languages.

Learn and improve, or don't learn and become unable to earn a living in the field.

Re:Strongly typed language?

[binary paladin]

I like your definition.

One of the biggest problems with "strongly typed" that I've seen is that sometimes it becomes synonymous with with "statically typed" and they just aren't the same thing. Some people seem to think that dynamically typed languages are automatically "weakly typed" which is just flat out wrong.

Re:Strongly typed language?

[Abcd1234]

Most languages are strongly typed so that's not a particularly useful metric.

Hardly. The One True Language for client-side web development, aka Javascript, is weakly typed, as is PHP, that ubiquitous server-side programming language. Perl is weakly typed. Good ol' shell script is weakly typed. Heck, even C is considered weakly typed (unless you enable -Werror, of course).

Bit more on the twitter culture.

[juuri]

Recently I decided to move from contracting to full time work as the job market is balls here in the Bay currently for Contracts. Twitter was one of the companies which I applied and I had the pleasure of having a "phone screen" with them for a senior unix position. Here's what this screen was, a basic unix question, that any lunix user could get. A more intermediate type question that could trick some people. And finally their *BIG SCREEN* a tricky question that was based on esoteric knowledge that had absolutely nothing to do with one's ability to perform the job.

The person calling me was just reading these off a list, she didn't know why they were picked and was only able to write down the answers. Here's the hilarious part, I informed her that the question was silly and there's no reason anyone should really care about this sort of information except in extreme situations. That this was the question that lead me to believe they had a culture of primadonnas. She diligently wrote all this down, in case they still wanted to talk to me.

But here's the REAL kicker, their stupid asinine esoteric question? Was wrong. They had the phrasing wrong... what they were asking and looking for in an answer were not the same things. Being a pedantic asshole, in my followup to tell them what I thought of their process I pointed this out. Never heard anything back ;) Wonder if they have fixed their question yet?

Re:Bit more on the twitter culture.

[MyLongNickName]

Wow! You sure showed them!

Re:Bit more on the twitter culture.

[iluvcapra]

Maybe they didn't care about Unix experience, and were primarily testing your personal skills and your ability to hold a pleasant conversation with a non-technical person over the phone.

Always keep an eye out for the psych test.

Re:Bit more on the twitter culture.

[juuri]

I was completely pleasant with the woman, we joked about the questions in fact. The simple fact was they had a stupid call screen process straight out the egotistical dot.com days, which showed much about the types of "engineers" they like to bring in.

Thanks for assuming that I was an ass thought. :)

Re:Bit more on the twitter culture.

[MaggieL]

But what if the interviewer was a Zaldan?

Re:Bit more on the twitter culture.

[iluvcapra]

Thanks for assuming that I was an ass thought. :)

You said yourself that you were a ... let me scroll it up here... a "pedantic asshole" who told the interviewer, quite presumptuously, that a question was "silly." Furthermore, completely on the basis of the phrasing of one question, you had concluded that the entire company had a "prima donna" culture.

Re:Bit more on the twitter culture.

[iluvcapra]

I'm not Mordoch, you insensitive clod! I merely share his genostructure!

Re:Bit more on the twitter culture.

[twiddlingbits]

they must have some of the old Amazon.com folks there. Amazon was like that. Same type of questions, same type of mistakes in what and how they asked the question except they did it in person. I had the same reaction as you did, told them they were wrong in the specification which led to their answer being an incorrect solution. They got pissed and ended the interview. I caught an early flight back :) Plus people were on call 24x7 and worked hellacious hours for low pay and lots of worthless stock options.

Re:Bit more on the twitter culture.

[mwvdlee]

She diligently wrote all this down, in case they still wanted to talk to me.

Point of case; they never DID want to talk to you again, did they?
Why employ somebody that considers difficult questions "esoteric knowledge that had absolutely nothing to do with one's ability to perform the job".
Perhaps that little bit of information is exactly the kind of thing you need to know if you're working on Twitter's systems.
Or more simply put; "There are no stupid questions, only stupid people".

Re:Bit more on the twitter culture.

[Korin43]

Saying that a question is silly is hardly an insult, especially if you're talking to someone who didn't come up with it..

Re:Bit more on the twitter culture.

[iluvcapra]

Saying that a question is silly is hardly an insult,

It presumes bad faith or ignorance on the part of the questioner. When having a polite conversation with a stranger, particularly one you wish to show deference, you should always give the speaker the benefit of the doubt, and never confront them for being ignorant or specious. Just concede they believe they know what they're talking about, indicate how this doesn't match your understanding of the issue, and move one. "Silly" is a put-down, and a woman in particular might consider this language to be condescending from a man. You might not consider that fair, but that's the breaks.

If they insult you, then you thank them for the interview and hang up. Haven't any of you ever done phone support before!?NEVER EVER EVER confront. It's simply never appropriate or effective.

Re:Bit more on the twitter culture.

[BitHive]

Sounds to me like their bozofilter worked perfectly.

Re:Bit more on the twitter culture.

[juuri]

Here's the question:

"What utility gives you information in an inode?".

They were being tricky and looking for "ls". This is not correct.

Esoteric was a poor choice of words by me, they were trying to be "too smart" for their own good and got caught up in making a mistake themselves. I've been doing unix work for quite a while (17+) across many environments and this sort of "screening" says huge amounts about the company involved and the work they do.

Re:Bit more on the twitter culture.

[mcvos]

Saying that a question is silly is hardly an insult,

It presumes bad faith or ignorance on the part of the questioner.

It presumes nothing. If the question really is silly, then it's an honest answer. If it's a trick question, it might even be the answer they're looking for. It's quite possible to politely inform someone that something is silly, and not doing so could be dishonest.

If I were interviewing prospective employees, I'd definitely prefer one capable of distinguishing silliness over one who tries to bluff his way out.

Re:Bit more on the twitter culture.

[What'sInAName]

Hmm, a colleague of mine had the same question from Google a while back. Are you sure they were looking for "ls"? (i.e., did she say that?) The answer of course, is "stat". (To be honest, that was a command with which I was unfamiliar until my colleague told me about the question. Since then, I've found it to be quite handy in certain situations.)

Re:Bit more on the twitter culture.

[iluvcapra]

If the question really is silly, then it's an honest answer

There's no such thing as a stupid question, particularly from an employer. The difference between an adequate tech and a great tech is the great tech can answer a stupid question in such a way that enlightens the asker without insulting their intelligence.

Of course this is slashdot, so I'm not surprised to find casually insulting people posting here. You just don't realize.

Re:Strongly typed language?

[Em Emalb]

It's kinda like "PC Load Letter".

to put it differently

[Fuzzums]

a language that can be used in many different ways will result in code that will be a JOY to maintain and debug.

Re:to put it differently

[anonymous cowpie]

Oh, you mean like C++? Or maybe Perl? Ugh, no thanks. You can keep your JOY.

Re:Miracle language.

[staeiou]

No, this is Scala, a language that is a blend of functional and object oriented programming. Scalia [wikipedia.org] is mix of textualism and originalism with a very conservative framework. Some consider its inability to recuse itself to be its greatest asset.

Eh, different tools for different jobs.

Re:Strongly typed language?

[StuffMaster]

http://en.wikipedia.org/wiki/Hyperlink

Sold on Scala

[mcpotato]

I have not only seen the book but also read it (assuming you mean Programming in Scala). It is very well written and gets you started with Scala easily.

I do not agree that the syntax is redundant. To the contrary: an important part of the language design is that Scala enables the programmer to extend the language using libraries. A good example is the way collections and iteration work in Scala vs. the way the foreach loop has been added in Java 5.

Whether static type systems help or hinder depends on whether you work with or agaist it, and on the kind of programs you write. The Scala type system is rather advanced (in the sense of complete) such that it allows you to express more in the type system than other languages do.

For Java style programming Scala is just much simpler and shorter to write. When you have written some code in both you can appreciate the way Scala works.

There has already been a comment on multi-paradigm programming, I do not have to extend that.

Re:Sold on Scala

[JSlope]

Another good book will be Beginning Scala Try it if you're Java programmer wanting to try Scala.

Re:Runs on Java JVM. Why bother?

[Ichoran]

Those supposedly cute features are there for a reason--they make abnormally clean and maintainable code possible.

The best Scala code I've seen is clearer (to an outside observer) than the best Java code could possibly be, since the language features allow you to focus more on what is going on rather than necessary theatrics.

The worst Scala code is, admittedly, worse than the worst Java code could possibly be.

So, if I had programmers who wrote nice clean code, I'd encourage them to use Scala. If I had programmers who wrote ugly tangled code, I'd force them to use Java.

Re:Strongly typed language?

[maxwell demon]

Obviously Java is weakly typed :-)

String s = 1 + 2 + " is not " + 1 + 2;

Re:Oooooooohhhh....

[PylonHead]

No question that anyone who wants to make a living programming probably needs to learn a business safe language like the ones you mention.

Still, some of us really enjoy programming, even when we aren't making a buck off it. Working with a new language can make you think about programming in a new way, and can teach you lessons that you can bring back to your day to day business work.

Let's not forget how fun masturbation can be!

Re:Strongly typed language?

[SatanicPuppy]

I actually really like dynamic/strong languages (like, for example, Python). It allows you the security and readability of a strongly typed language, without all the whiny syntax of a statically typed language.

Java cured me of ever liking static typing...Seems like I spend half my time in java dealing with weird casting issues.

Re:Oooooooohhhh....

[Abcd1234]

Yes, but understand that, when you're learning that language, you're doing it to expand your mind and development toolkit, *not* to add said language to the list you put on your resume, as the very fact it's niche means no one will care.

And by "development toolkit", I mean things like design patterns and approaches to software construction. Take Haskell, for example. Compared to a typical imperative language, it requires a *very* different mindset when constructing applications. But the lessons you learn (higher-order functional programming, function composition as a form of abstraction, etc) are powerful tools which can be utilized in other languages, and learning them will force you to re-think how you build software, which is a very good thing.

Re:Strongly typed language?

[Migala77]

Yes, big difference; all combinations are possible:

Strong and Statically typed: Scala, Java, C++
Strong and Dynamically typed: Python, Ruby
Weak and Statically typed: C
Weak and Dynamically typed: PHP, Perl, Javascript

Re:Strongly typed language?

[SporkLand]

Here is a great resource on these issues and might help you use some of the language you are using correctly:
http://www.pphsg.org/cdsmith/types.html

I understand that static versus dynamic is a fairly binary valued property, but my understanding is that strength of type systems is real valued.
There are 2 axes to strength:
1. If you have a type system (you outlaw certain programs), how well is it enforced? Are there ways to get around it? (Yes/No)
2. How many and what type of behaviors do you outlaw in programs. On this axis a lot of trade offs can be made. Do you allow automatic coercion? Do you allow generic data types to be expressed? If so, are covariant and contravariant type parameters allowed? etc... (Subjective 0.0 - 1.0)

Re:Strongly typed language?

[SporkLand]

Unfortunately I don't have a link handy that will help me use English correctly.

Re:Strongly typed language?

[SatanicPuppy]

Perl is weakly typed on a lot of things, but it's static for data structures and subroutines.

So you can have a hash of hashes, or an array of arrays, but you can't get arrays in your hashes or vice versa.

Php gets around that by having only one datastructure that tries to pretend to be other types of data structures, just without, you know, doing it very well.

Re:how impressive is the twitter implementation

[SatanicPuppy]

It depends on which language you use. A lot of people blame Twitters early problems on Rails, which has notorious scaling issues.

//Angry Ruby fanboy comments start below

Re:Strongly typed language?

[shutdown -p now]

Perl is weakly typed on a lot of things, but it's static for data structures and subroutines.

So you can have a hash of hashes, or an array of arrays, but you can't get arrays in your hashes or vice versa.

Yep. I mainly referred to Perl's and PHP's ability to treat strings as numbers and vice versa, depending on the context - Python wouldn't let you get away with that, for example. In that sense VB6 was also weakly typed, even though it had strongly typed objects.

Re:Strongly typed language?

[gardyloo]

So you can have a hash of hashes, or an array of arrays, but you can't get arrays in your hashes or vice versa.

Yo, Puppy, I heard you like arraying your hashes and hashing your arrays, so we put ... Oh, nevermind.

Re:Oooooooohhhh....

[Rising Ape]

You assume that the only reason to learn something is to make money with it. Which is a rather depressing worldview, really.

Why I Hate All Programming Languages

[Louis Savain]

"I hate computer languages because they force me to learn a bunch of shit that are completely irrelevant to what I want to use them for. When I design an application, I just want to build it. I don't want to have to use a complex language to describe my intentions to a compiler. Here is what I want to do: I want to look into my bag of components, pick out the ones that I need and snap them together, and that's it! That's all I want to do." Quoted from Why I Hate All Programming Languages.

Functional languages are worse because they are painfully counterintuitive. I don't want to write a function if all I want to do is link a sensor directly to an effector. Drawing a line from A to B is an order of magnitude simpler. Which is the way it should be.

Re:Why I Hate All Programming Languages

[jbolden]

That "why i hate" is a terrible editorial. What he is saying is that he doesn't want to think carefully about what he's doing. His objection isn't to languages really it is to clarity of thought. Tinkering and right brain is great for art, it isn't the right mode for engineering.

Re:Why I Hate All Programming Languages

[setagllib]

So who do you think will be writing the "components" for your magic system, and the infrastructure to make the system executable, designable, testable and usable? We have been progressing to increasingly high level code (and in some cases, as you say, component architectures), but the amount of code being written and maintained continues to grow, not shrink.

So the amount of code is growing, and it does more per unit mass, and software engineering skills are increasingly valuable and applicable, and you think this is a trend towards the elimination of code and software engineers? You may want to check your water and food sources for contamination.

Re:Why I Hate All Programming Languages

[jbolden]

I'm not too worried. The idea behind COBOL was that once you got rid of that mathy way of writing code anyone could do it. The fact is that taking a process and breaking it into a series of steps and dealing with all the cases takes practice. The problem is not syntax or language structure the problem is thinking through a problem that way.

Until computers have common sense all languages are going have to look like

Do X
Read Y
Y Case 1 ...
Y Case 2...
Y Case 3....

Re:Why I Hate All Programming Languages

[chthonicdaemon]

Of course, intuition is not the same for everyone. I find object-oriented languages 'painfully counterintuitive', but I have the good sense to realise that it's working for many people and it may be my personal experience (or lack thereof) that is making the process painful, rather than the actual technology.

Re:Why I Hate All Programming Languages

[Louis Savain]

So who do you think will be writing the "components" for your magic system, and the infrastructure to make the system executable, designable, testable and usable? We have been progressing to increasingly high level code (and in some cases, as you say, component architectures), but the amount of code being written and maintained continues to grow, not shrink.

If software apps were purely compositional and organized as a hierarchical tree, the low level components would need to be written only once. Once the bottom levels (mostly leaves) of the tree become populated, then all of the higher level apps will be compositions of existing objects. Plug and play. The trick is in the purely compositional part: everything must be compositional from the bottom up.

So the amount of code is growing, and it does more per unit mass, and software engineering skills are increasingly valuable and applicable, and you think this is a trend towards the elimination of code and software engineers? You may want to check your water and food sources for contamination.

I think it will be the elimination of the traditional programmer, because a time is coming when everybody will be a programmer whether they know it or not. Drag'm and drop'm, that sort of thing.

Re:Why I Hate All Programming Languages

[cripkd]

Will the huge Minority-Report-touch-screen we'll all have in our homes be a result of this architecture you're describing or will it be a requirement for developing it?
Since you mentioned drag'n'drop I think it will be the second.
So we'll wave our hands around to program... Enter the STS (Shoulder Tunnel Syndrome).

Re:Why I Hate All Programming Languages

[mcvos]

If software apps were purely compositional and organized as a hierarchical tree, the low level components would need to be written only once. Once the bottom levels (mostly leaves) of the tree become populated, then all of the higher level apps will be compositions of existing objects. Plug and play. The trick is in the purely compositional part: everything must be compositional from the bottom up.

But software already is a hierarchical tree, and many components have been written once (for each version of each language for each platform). We're using much higher level primitives than we were using decades ago, and we're writing much more complex programs with them. But that doesn't mean you suddenly don't have to think anymore. Quite the contrary. We're using our more powerful tools to do more impressive things.

I think it will be the elimination of the traditional programmer, because a time is coming when everybody will be a programmer whether they know it or not. Drag'm and drop'm, that sort of thing.

What do you mean by "the traditional programmer"? We don't write full applications by flipping switches anymore. Programming is a lot more accessible than it used to be. You don't have to worry about memory allocation anymore. That is, most people don't. But the people who write our compilers and VMs still do. They're not going anywhere, they're just making the job easier for higher-level programers.

No doubt programming will continue to become increasingly more accessible to normal people (see the LEGO Mindstorms programming system, for a good example), but educated programmers will continue to use the additional power to make even more impressive programs.

Re:Why I Hate All Programming Languages

[jbolden]

f software apps were purely compositional and organized as a hierarchical tree, the low level components would need to be written only once. Once the bottom levels (mostly leaves) of the tree become populated, then all of the higher level apps will be compositions of existing objects. Plug and play. The trick is in the purely compositional part: everything must be compositional from the bottom up.

That's called object oriented programming it has been the dominant paradigm for a generation. Turns out that in reality:

1) Highly generic objects are very abstract and hard to use, too mathy

2) Moderately generic objects are incredibly expensive to write and maintain though very very useful. Of course you need an order of magnitude or more more of them than highly generic.

3) Slightly generic objects are cheap but essentially single purpose.

The ones that only have to be written once are the most abstract ones.

Re:Why I Hate All Programming Languages

[Anonymous Coward]

I think it will be the elimination of the traditional programmer, because a time is coming when everybody will be a programmer whether they know it or not. Drag'm and drop'm, that sort of thing.

At first, I thought you were asking questions about something you didn't understand. Then, it became you giving advice on something you didn't understand. But now, I think I understand. It was penis envy all along.

Re:Why I Hate All Programming Languages

[jbolden]

Programming is a lot more accessible than it used to be. You don't have to worry about memory allocation anymore. That is, most people don't. But the people who write our compilers and VMs still do. They're not going anywhere, they're just making the job easier for higher-level programers.

Just to make it worse that isn't quite as "still". That sort of stuff comes into and out of fashion. The 1950s COBOL programmers and 1970s LISP programers don't worry about that stuff either. Dealing with hardware at a low level is important when hardware efficiency is important. Ask game programmers on consoles if they worry about that sort of stuff. Cell phones seem like a prime place where efficiency is likely important just the hardware is changing too fast. Once the hardware improvements on cell phones start to slow....

What has gotten better are languages that are more in the middle that allow you to worry about some of it some of the time but mostly ignore it.

Re:Why I Hate All Programming Languages

[jejones]

For those who don't follow the link: M. Savain is quoting himself.

I look forward to the day when he actually implements his supposed Holy Grail of programming and announces its availability--though that would require, at least at first, that he learn one of those languages he hates.

Re:Why I Hate All Programming Languages

[joss]

This visual programming crap crops up from time to time because so many people are brainwashed by that crap about a picture being worth a 1000 words. Draw me a picture of "misguided".

This is also the reason why the GUI monkeys can never understand the power of a command line. The command line is a language. They are stuck on the "pictures are better than words" meme. Yes - certainly, until you learn to read.

Visual stuff, GUIs, languages etc, are more *intuitive* in the same way that picture books are more intuitive to babies. It doesn't mean they are superior. This is why the best interfaces are a combination of GUI and language. It's just like the way you give children picture books while they are learning to read. The fastest way

I took a look at your COSA stuff.. good luck, but you're barking up the wrong tree.

Programming is done with languages because programming is communication. It's communication between programmer and computer.

If the kind of drag and drop stuff you are proposing was a better mechanism for creating complex programs than languages, then we wouldnt use languages to communicate with each other. Instead we would push a bunch of colored blocks around and drag string between them. I don't think we're going to start doing that anytime soon either.

Re:Why I Hate All Programming Languages

[maharg]

If the kind of drag and drop stuff you are proposing was a better mechanism for creating complex programs than languages, then we wouldnt use languages to communicate with each other. Instead we would push a bunch of colored blocks around and drag string between them. I don't think we're going to start doing that anytime soon either.

This is quite possibly both the funniest and most insightful comment *ever*. Kudos to you joss.

Re:Why I Hate All Programming Languages

[Louis Savain]

Will the huge Minority-Report-touch-screen we'll all have in our homes be a result of this architecture you're describing or will it be a requirement for developing it?

Interesting that you should mention this because I wrote about it on my blog some time ago. Well, it was actually about Jeff Han's multi-touch screen technology, which is the same thing. So yes, I think it will be an ideal interface for the future of parallel programming.

Let me add that the main reason that compositional development tools have failed is that they are inherently algorithmic. What is needed is an implicitly parallel model.

Re:Why I Hate All Programming Languages

[Louis Savain]

Programming is done with languages because programming is communication. It's communication between programmer and computer.

Sure, this what it is now because the computer, as we know it, was originally invented by mathematicians for mathematicians (Babbage and Lovelace). As we all know, mathematicians are obssessed with algorithms, i.e., language. The truth is that programming, like all activities having to do with constructing something, should be about construction and nothing else. We understand what we want to construct. We should not have to express it it in a language unless we absolutely have to. Construction implies things like building blocks, parts, and effective tools with which to manipulate said blocks and parts. It has very little to do with syntax, keywords and vocabularies.

Rile as much as you want but the future of computing is not linguistic. It is time to move away from the current descriptive nature of programming to one that is purely constructive. This is where things are going and neither you nor anybody else can stop it. Sorry.

Re:Why I Hate All Programming Languages

[angel'o'sphere]

Visual stuff, GUIs, languages etc, are more *intuitive* in the same way that picture books are more intuitive to babies. It doesn't mean they are superior. This is why the best interfaces are a combination of GUI and language. It's just like the way you give children picture books while they are learning to read.

Well, as concrete answer to the above: then textually describe me a map of the landscape around ... hm, lets say 52 norht, 2 east. I would assume a picture says more than a million of your words, I prefer a map and depending on what I want to do I prefer a topological, a nautical, a watterway or a avionic map.

While your general idea that GUI monkeys don't knwo the value of a command line might be right, all your ranting is just bullshit nevertheless.

Try to pilot a fighter via command line ...

angel'o'sphere

Re:Why I Hate All Programming Languages

[badkarmadayaccount]

Yeah, cuz humans deal great with implicitly parallel... Ever try Verilog?

Re:Why I Hate All Programming Languages

[badkarmadayaccount]

That's procedural, which is in contrast with functional.

Re:Why I Hate All Programming Languages

[jbolden]

Not really.

f y = case y of
  1 -> A1
  2 -> A 2
  3 -> A3 ...

main do y - get.. (x...)
                  t = f y

not really any different.

Re:Why I Hate All Programming Languages

[civilizedINTENSITY]

You draw the line, sure. But does it do what you intend? Is the data transfer synchronous or asynchronous? Do you need a buffer? Soft real-time? Hard? It just doesn't matter? Are going to want events triggered if the input signal reaches certain stages? Does the time rate of change of the signal matter as well as the value? Oh? You want a weighted average of the value and its rate of change?

Don't get me wrong. Its easy to design a system like you describe so long as you like what I feel that line represents. Hell on you if you don't, though. If you want input as to what that line represents, you'll have to express your intentions. We use language for that.

Re:Why I Hate All Programming Languages

[badkarmadayaccount]

Makes a world's difference when making a compiler.

Re:Why I Hate All Programming Languages

[jbolden]

How is it different when making a compiler?

Re:Why I Hate All Programming Languages

[setagllib]

Let's say that programming is /already/ composition from a hierarchical tree of components, and that the most basic components (that we care about) are CPU and device instructions. Then let's say that above that level we have system calls, low-level functions, resource abstractions, classes, domain-specific modelling, etc. and that all of this is a perfectly valid composition of components.

Then let's say that the only difference you actually want is to put all of this together with a graphical editor instead of a text editor. Is that fair to say? If that's all you want, then learn to write code, because that's a lot more practical. You're the one that's wrong, not the industry.

If you seriously want components to be designed specifically for graphical composition instead of logical composition, well, that's when you know you're in the wrong industry.

You are ignoring, either through sheer ignorance or a commercial agenda, the wealth of literature and experience on how incredibly impractical it is to shoehorn complex logic and relationships into graphical forms, and especially how difficult it is for a human to interpret (let alone manipulate) the result of such a transformation. Return to the material plane and learn to program correctly, or stay out of the industry.

Re:Why I Hate All Programming Languages

[setagllib]

I for one completely agree. As someone for whom generality is code porn[1], it's been my experience that every little extra bit of generality introduces an order of magnitude more code. In practice this should still save you code compared to repeating yourself for every case, but at some point the costs outweigh the gains and you have to draw a line.

[1]: I like to combine C++ templates and polymorphism. Most people don't, but if you're willing to battle those demons, you can make extremely reusable code, that's still type-safe at compile time. I'll take Scala over that any day, but it's a fun exercise.

Re:Why I Hate All Programming Languages

[badkarmadayaccount]

Try making compilers for a procedural, and a functional language, and call me.

Re:Why I Hate All Programming Languages

[jbolden]

I have in fact the most popular compiler in the world .NET does both (C# & VB vs F#). GHC used to compile to GCC.

Re:Strongly typed language?

[RedMage]

Yeah, that would bring new meaning to "Strongly Typed" that I don't think was intended...

"Damn John, that brain fart was really strongly typed!!"

Re:Strongly typed language?

[mwvdlee]

To make matters more difficult, most languages are somewhere in between "pure" strongly typed and weakly typed.

Re:Reinventing the wheel is sometimes good

[Haeleth]

It's somewhat related to Java (Scala programs execute with the JVM).

IIRC it was originally intended to be able to use the JVM or Microsoft's CLR; they just finished the JVM version first and that's what's being promoted.

It's certainly a terse language. That's both good and bad.

Terseness is largely irrelevant. The right question is not "does this language let me express something in the minimal number of keypresses", but rather "does this language force me to repeat myself endlessly".

Scala has good support for abstracting code; Java, for example, does not. That means that code written in Scala could well be more maintainable (changes need to be made in fewer places), and it also means it's likely to be better quality (people are less likely to copy and paste if it's just as easy to do it properly).

I ran into this just today. I had a bunch of copy-and-pasted code that I was trying to refactor into a sane design, and Java thwarted me at every step. I could see why the original coder had given up! Eventually I had to resort to a hack using reflection, which of course lost me all the benefits of static typing. Thanks, Java. But at least the core algorithm is now stored in exactly one place, instead of there being ten copies of it scattered across as many files.

Wrong, wrong, and.. wrong..

[synthesizerpatel]

>> , the rest of us either (a) remember the types of our variables

1) Strong typing helps compilers and processors, not programmers. A weak programmer wouldn't understand the value of a strongly typed language.

2) Any developer who says he 'remembers the types of our variables' is either lying, or inexperienced. You may remember it today, a week from today, or perhaps even a month. You will not in a year. Nobody who looks at your code will 'instantly know' unless you name your variables 'thisIsAnUnsignedInt32', which, would be pretty silly.

3) SE Asia and India produce many fine programmers (FYI, I'm a caucasian american, so no favoritism.). because of the lower prices of programmers from India and SE Asia you're statistically likely to see _more_ of them, hence more bad programmers.

Re:Reinventing the wheel is sometimes good

[CarpetShark]

Perl already has brainfuck-like syntax.

There, fixed that for you.

Re:Strongly Typed programming languages

[SoftwareArtist]

Strong typing helps _only_ weak programmers, the rest of us either (a) remember the types of our variables or (b) expect "1" + "2" -> 3, not "12".

As a programmer with 25 years of experience, I could hardly disagree more. When developing any large project, static typing is hugely beneficial. It lets you catch far, far more errors at compile time. In a dynamic language, those would all be runtime errors that could easily slip through your testing and make it out to a customer. It makes automated refactoring possible. (Ever try doing a major restructuring of a 500k line code base written in a dynamic language? Good luck!) It enables all sorts of static analyses that let you be a more productive programmer. Try using a really good Java IDE like Intellij IDEA, then try the best Python or Ruby editor available, and you'll feel like you've gone back to the stone age. No "Find Usages"? No autocompletion? No "Go to Definition"? You simply can't do these things in a dynamic language, because the editor has no idea what the type of any variable is.

This isn't meant to criticize dynamic languages. They definitely have their place. But 90% of the symbols in most programs should be statically typed. I don't see why more languages don't simply offer both options. In those that do (e.g. Groovy), type declarations are simply optional. If you declare a type, it gets checked at compile time. If you don't, that symbol becomes dynamically typed. It works very well.

Re:Runs on Java JVM. Why bother?

[Asian Freud]

Hey. Seems like you hate every languages ever conceived!

What's your favorite language?

Re:Reinventing the wheel is sometimes good

[bsDaemon]

As to Perl's object model, I couldn't agree more. However, from CPAN you can get Moose and MooseX which really clean things up a lot and hide the nasty bits. For instance, with MooseX::Declare, the following is now valid Perl:

use MooseX::Declare;
class Car {
          has make => (isa => "Str", is => rw"); # setting a member... they are in a hash type of thing

          #some simple methods

          method set_make (Str $make) {
                    $self->{"make"} = $make;
          }
          method return_make {
                    return $self->{"make"};
}

I just learned about the MooseX stuff yesterday, so of course my example isn't anything super, but as you can see, it's pretty god damned simple comapred to the alternative.

static typing != strong typing

[speedtux]

According to common usage, Python and Scheme are both "strongly typed" as well, since they guarantee that all type errors in programs are detected. This is in contrast to "weakly typed" languages like Perl or K&R C, in which many type errors are silently ignored. That is, all four combinations of strong/weak and static/dynamic typing are possible.

Some people are using the term "strong typing" as a synonym for "static typing"; I wouldn't really care, except that there is no good other term to describe what "strong typing" means.

From a practical point of view, it seems pretty clear that "strong typing" (in the first sense) is important, but I have seen little evidence that static typing is all that useful in a general purpose programming language.

Re:static typing != strong typing

[speedtux]

Perl is quite strongly typed. It's only types are scalar, array, and hash [...]

Sorry, but that's not a useful point of view; automatic coercion like that is a form of weakness in the type system.

If you look at a C array as an int, you get its address in memory and party all over it.

That's wrong. Neither K&R nor ANSI C defines what you get when you look at an "array as an int".

Re:static typing != strong typing

[angel'o'sphere]

... but I have seen little evidence that static typing is all that useful in a general purpose programming language.

That is a matter of the way how the mind of a particular developer works.
I have troubel with dynamic typing, and I hate it to get me my errors shown by runtime when a compiler could have detected that error. Some people don't have this trouble, so they don't need static type checking. Other people develop even the simples script in a test driven development approach and don't need static types either.

However: even simple typos like foo.baar() // should be one a only ...
get compiled by dynamic languages and lead to an runtime error: method baar() not found! I make such typos in the hundrets a day, if I was forced to use languages like python I would hang myself.

angel'o'sphere

Re:static typing != strong typing

[Andrew Cady]

I have seen little evidence that static typing is all that useful in a general purpose programming language.

Static typing means that the compiler knows the type of every value. This allows the compiler to produce faster code. In particular, it allows the compiler to avoid a layer of indirection through a pointer. By contrast, in traditional implementations of LISP, all variables except integers are represented as pointers: that is why LISP is (or is reputed to be) slow. Moreover, the type of the value (even integer values) is represented in the data, and must be checked. The more information the compiler has about typing, the more of those pointers and checks can be eliminated, thus the less code and less memory access is necessary to get data into a register. In the ideal case, the data is put into a register directly through the assembly produced by the compiler. That's going to happen all the time with C; it won't happen in a dynamically typed language unless a lot of work has gone into optimizations (meaning, generally, "whole program analysis") or the programmer specifies additional type information for the compiler.

So, the point of static typing is not to help you, the programmer; it is to help your compiler.

Re:static typing != strong typing

[Andrew Cady]

However: even simple typos like

foo.baar() // should be one a only ...

get compiled by dynamic languages and lead to an runtime error: method baar() not found! I make such typos in the hundrets a day, if I was forced to use languages like python I would hang myself.

http://www.google.com/search?q="used only once: possible typo at"

Re:static typing != strong typing

[Just Some Guy]

However: even simple typos like foo.baar() // should be one a only ... get compiled by dynamic languages and lead to an runtime error: method baar() not found! I make such typos in the hundrets a day, if I was forced to use languages like python I would hang myself.

In Emacs, I have F1 bound to (pylint), which scans my program for all sorts of errors, including those. It's not perfect and I often end up disabling some of its warnings - "yes, I know this block looks odd, but I know what I'm doing and I meant it to be that way" - but it's very good at what it does. Consider that running pylint isn't inherently different from running javac and looking for warning and errors.

Re:Strongly Typed programming languages

[speedtux]

LISP, Perl and OCaml are far more useful than C++, Java and C#

Let's see:

• Lisp: strongly, dynamically typed
• Perl: weakly, dynamically typed
• OCaml: strongly, statically typed
• C++: strongly, statically typed (some holes in the type system)
• Java: strongly, statically typed
• C#: strongly, statically typed

I'm not sure what point you're trying to make, but it doesn't seem to have anything to do with either strong typing or static typing.

The academic idiots,

That's as opposed to the non-academic idiots, who apparently don't even know what "strong typing" means.

Re:Strongly typed language?

[bsDaemon]

You can totally make hashes of arrays and arrays of hashes... http://www.perlmonks.org/?node_id=1977

Re:Strongly Typed programming languages

[jbolden]

Try the more advanced languages. Once you have strong typing you can have variables that are of types like:

function of a string, int and a char to a string and then when you apply a char to it the system knows you now have a function of type string and int to string.

Re:Reinventing the wheel is sometimes good

[andy_t_roo]

yes, the similarity is immediately obvious

--BF code for hello world removed because i was unable to get it past the junk filter. (http://www.roesler-ac.de/wolfram/hello.htm)

# Hello world in perl
print "Hello World!\n";

Re:Strongly typed language?

[Ann Coulter]

What would be the result of 354+true? What is the result of true+true? What is the result of false-true? What is the result of true^3? What is the squareroot of true? Does it make any sense? Is it well defined?

In C, any non-zero int value is synonymous with true and the int value 0 is synonymous with false. So, 354+true is something besides 354; true+true is the sum of two non-zero int values; false-true is simply the arithmetic negation of some non-zero int value; true^3 is some non-zero int value multiplied by itself twice; sqrt(true) is some non-zero int value cast into a double and given to sqrt. It does not have to make sense because these operations are well-defined.

Re:Strongly typed language?

[libkarl2]

I don't mean to sound pedantic, or borish, but C is actually "yeah baby yeah" typed, to enable pointer arithmetic, stack space exhaustion, buffer overflows, and system level development. It's not incorrect to say that it is weakly typed, per se. It's just awkward having to try to explain the direct parallels between the C type system and a 70s style love-in (where anything goes) -- to your manager.

Re:Strongly typed language?

[SL Baur]

I'll pass on Javascript as with PHP. Perl is strongly typed, but not statically typed - you add an integer variable to a floating point variable and you will get a numerically reasonable result, unlike something like B.

Lisp is strongly typed. Using an example from an implementation I know best, Emacs Lisp is strongly typed - a cons cell always has a type tagged to it that is enforced by the interpreter. The fact that symbols may be bound to different cons cells in their lifetime matters nothing with respect to strong typing. Obviously, there is no static typing whatsoever.

C was originally a weakly typed language that has moved in the direction of static (but not strong) typing (with GCC extensions). Obviously, untagged unions blow any kind of type checking out of the window. Tagged, honor system unions also defeat static analysis. Unconstrained typecasts prevent C from ever being more than that.

The Unix Shell, has always been strongly typed. The grandfather of them all had every type as a string. More modern equivalents have integer and floating point types and those are strictly tagged.

If a language is strongly typed, then a + i where a is 1.0 and i is 1 will give a sensible result because either the runtime or the compiler will convert the integer to floating point and give the numerically correct answer. In a statically typed language, an error will be thrown at compile time.

Static type checking is particularly important for critical code like CGI and core O/S. The only grey area is when your input consists of bits coming across a wire or from some random H/W device. In that case you must always handcode the type checking.

Strong typing means that the compiler and the (optional) runtime always knows what type an object is. Static typing means the compiler always knows what type an object is and can refuse to compile something in violation of the established typing rules. There is a big difference.

Re:Strongly typed language?

[andy_t_roo]

that is simply caused by associative and automatic conversion -- i'm sure you could configure the compiler to throw a warning in this situation.

this needs three functions, one of which is implicitly called (actually builtin in this case, but you could easily be adding shapes and strings, it would make as much sense)
int plus (int, int)
string plus (string string)
string int2string(int)

3=plus(1,2)
"3 is not " = plus(int2string(3)," is not ")
"3 is not 1" = plus("3 is not ",int2string(1))
"3 is not 12"= ...

(unless it evaluates the other way, to 12 is not 3, its been a while since i've done any real programming, and things like this only come up once in a blue moon.)

Re:Reinventing the wheel is sometimes good

[SL Baur]

Terseness is largely irrelevant. The right question is not "does this language let me express something in the minimal number of keypresses", but rather "does this language force me to repeat myself endlessly".

I did not mean "terseness" to be a pejorative. Length of code can sometimes and sometimes not be of assistance to the poor bastards maintaining it after the original developer has gone.

It's my fate in my career that I have been primarily maintaining other people's code and personally, I have an easier time reading small snippets of code in small functions than the multi-K lines of deeply nested if-else/etc. that certain coders prefer.

That was actually a dig on the four-letter P-word which can be compressed into incomprehensibilty.

The stuff I saw on the Scala website looked quite nice and terseness and reducing repetition appears to be one of their stated goals. I applaud them for that. Any time you have enforced repetition, maintenance costs go up regardless of how strict or sane the development environment is.

I need to rewrite a bunch of super-crap CGI code from scratch and I was planning on looking at something Scheme-ish to see if that would work (the core code I would like reuse is all in Emacs Lisp). I do plan on looking deeper into Scala before I propose anything because the Java tie-in might be easier for me to handle politically.

Re:Strongly typed language?

[SL Baur]

I don't mean to sound pedantic, or borish, but C is actually "yeah baby yeah" typed, to enable pointer arithmetic, stack space exhaustion, buffer overflows, and system level development. It's not incorrect to say that it is weakly typed, per se. It's just awkward having to try to explain the direct parallels between the C type system and a 70s style love-in (where anything goes) -- to your manager.

I hear where you're coming from, brother /.er.

I'm rather amazed at what work has been done in the Linux kernel regarding moving the code towards the static typing model with innovations in C and GCC extensions. Much of the Linux kernel *can* be statically type checked.

I am *so* hoping that Linus writes the Mythical Penguin Month as Fred Brooks did for O/S 360 the 3nd most important O/S, but most important at the time. For all his sometimes abrasive writing style, he has done something I didn't think could not be done. Well more than one something.

Re:Strongly typed language?

[bay43270]

The point made by the GP was valid:
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems
He said 'most languages are strongly typed' and he is correct. Pointing out 3 weakly typed languages doesn't make him wrong. It's also not the point of his post. The article was probably mistaken for describing Scala as a strongly typed language. While true, it's about as relevant as calling it a language which supports for loops. It's easy to assume they meant to describe it as a static language, since that differentiates it from it's popular competitors (Ruby, Groovy & Python).

From the summary...

[danwesnor]

...it sounds like an absolute mess for anybody but the guy who wrote the code.

sql wrappers

[chaostaco]

All you need to code Twitter is any language that can wrap SQL....

Add tweet: INSERT TABLE x (x) VALUES (@x, @userId)

Retrieve tweets: SELECT * FROM x WHERE UserId = @userId

I do respect some aspects of Scala, but using Twitter as a mark of success is worse than Hello World.

Re:Strongly typed language?

[Abcd1234]

I'll pass on Javascript as with PHP. Perl is strongly typed, but not statically typed - you add an integer variable to a floating point variable and you will get a numerically reasonable result, unlike something like B.

And add an integer and a string, and you'll probably get a numerical result, but it may not be what you expect, because just like Javascript, Perl does dynamic coercion at run time.

So I have to violently disagree with you, here. The minute a language does free type conversions at runtime without erroring out it's most definitely *not* strongly typed. At best, Perl falls somewhere in the middle, but to call it strongly typed destroys any meaning the phrase has.

Strong typing means that the compiler and the (optional) runtime always knows what type an object is.

No, strong typing means the compiler and/or runtime *enforce* the typing rules, either statically (ie, at compile time) or dynamically (ie, at runtime). The minute a language (like Perl or Javascript, both of which behave identical in this regard) performs dynamic coercion automagically, sorry buddy, you don't have a strong typing system.

The real problem is that people seem to view the term 'weak typing' as a perjorative. It's not. There's nothing wrong with Perl having a weak typing system. It means it's incredibly flexible, and especially great if you want to throw something together very quickly. Conversely, strong typing can be a huge pain in the arse (sometimes I *don't* want Python's runtime throwing friggin' typing exceptions at me all the time). It's all about tradeoffs.

Re:Oooooooohhhh....

[david_thornley]

Not much for professionalism, are you? I can say with about 99% certainty that the fact that you know Haskell will have absolutely no effect on your career. The fact that you learned it will have a large effect on how well you can turn problems into programs.

The only stable asset you have is you. If you don't improve yourself, you'll get left behind, and in ten years you'll be working on legacy C# systems and not getting paid as much as the people working on the interesting stuff in whatever language is new and hot next decade.

I've watched small computer development be dominated by BASIC, Pascal, C, C++, Java, and C# (with a lot of Visual Basic thrown in). I have absolutely no reason to suspect it all stops here. Learn or die.

Re:Strongly typed language?

[Abcd1234]

Pointing out 3 weakly typed languages doesn't make him wrong.

Well it does, indirectly. While you're right, in that in sheer numbers strongly typed languages outnumber weakly typed ones, the claim tacitly downplays the fact that three of the most popular languages in computing today *aren't*. As such, the OP's conclusion, that the strength of the typing system doesn't matter, is unsupported by the evidence.

"grows even bigger now with F#"

[alexmin]

Brilliant! ;-)

YAHLL (Yet Another Haskell-Like Language)?

[Hurricane78]

The summary reminded me of this:
http://www.willamette.edu/~fruehr/haskell/evolution.html

But I can't say that I'm not Haskell "biased". After all I tasted "her". And this resembles the experience best:
http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/044101.html

Re:Strongly typed language?

[chthonicdaemon]

Actually, C is a prime example of a weakly/statically typed language. The existence of a void pointer (or, actually, values in memory that are not tagged as being of a particular type) means that any piece of memory could be accessed as though it was any type. I could, for instance create an integer variable and a string variable pointing to the same piece of memory in C. This is weak typing. If there was a mechanism that explicitly forbade me from accessing a piece of memory which has been marked as 'type A' as 'type B', we have strong typing. If this can be enforced at compile time, we have static typing. Automatic type conversion does not really require weak typing if the coercion rules are well defined.

Re:Reinventing the wheel is sometimes good

[linguizic]

C++ is only the backend language for at least two of the sites you mentioned. Yahoo runs mainly on PHP hence Rasmus working there and Google, though I can't speak to what extent they use it felt it was in their best interest to bring on the creator of python.

bad puppy Re:Strongly typed language?

[Fubari]

SatanicPuppy wrote...
> Perl is weakly typed on a lot of things,
> but it's static for data structures and subroutines.
> So you can have a hash of hashes, or an array of arrays,
> but you can't get arrays in your hashes or vice versa.

Bad puppy :-)
I would like to mod that post '-1 good intentions w/ignorance'.

Thank you, bsDaemon.

It is worth looking at the code in bsDaemon's link.
For all the jokes about perl code being read-only,
this is really pretty clear:
--- begin excerpt ---
Answer: How do I make a hash of arrays?
contributed by chromatic

my %dramatis_personae = (
    humans => [ 'hamnet', 'shakespeare', 'robyn', ],
    faeries => [ 'oberon', 'titania', 'puck', ],
    other => [ 'morpheus, lord of dreams' ],
);

Access it like this:

foreach my $group (keys %dramatis_personae) {
    print "The members of $group are\n";
    foreach (@{$dramatis_personae{$group}}) {
        print "\t$_\n";
    }
}
--- end excerpt ---
(I'm guessing 'Hamnet' is a typo).
Anyway...
There are other ways to do this in perl, but the *intention*
should be pretty clear.

Just for fun, does anybody here have a corresponding Scala example?

Re:Strongly typed language?

[SL Baur]

add an integer and a string, and you'll probably get a numerical result, but it may not be what you expect, because just like Javascript, Perl does dynamic coercion at run time.

Because objects are typed. What would the result be in weakly typed language like C where you do 1 + "1234"?

So I have to violently disagree with you, here. The minute a language does free type conversions at runtime without erroring out it's most definitely *not* strongly typed.

Um, that's part of the definition I gave as a distinction between statically typed languages and strongly typed languages.

No, strong typing means the compiler and/or runtime *enforce* the typing rules, either statically (ie, at compile time) or dynamically (ie, at runtime). The minute a language (like Perl or Javascript, both of which behave identical in this regard) performs dynamic coercion automagically, sorry buddy, you don't have a strong typing system.

It's late, I'm tired, just pass the bowl over to me brother /.er and I'll take a hit off of whatever it is you're smoking.

Strong typing != static typing. Period. Nearly all modern languages and all "scripting" languages are strongly typed, but not necesarily statically typed.

Re:Strongly typed language?

[TheTurtlesMoves]

I have always viewed C as syntax sugar for assembly.

Re:Reinventing the wheel is sometimes good

[mcvos]

But if all you're doing is reinventing Perl with C-like syntax, it's not really a step forward.

Any change to Perl's syntax is a step forward.

(No idea what this has to do with Scala, though.)

Re:Reinventing the wheel is sometimes good

[mcvos]

The code snippets on the website http://www.scala-lang.org/ are intriguing. It's certainly a terse language. That's both good and bad.

Terse is mostly good, as long as it doesn't come at the cost of readability (see Perl for an example of that). Scala, while being about as terse as Ruby, doesn't seem to be quite as readable, unfortunately. But maybe the code snippets I've looked at aren't the best examples.

Re:Reinventing the wheel is sometimes good

[DuckDodgers]

If C++ was well suited to web application development, it would be a very common choice for websites. Instead, Google, Ebay, and Yahoo need the performance it offers for their high volume websites. Most smaller volume websites and many of the competing high volume websites are willing to skip the performance of C++ for the faster development time and easier maintenance from using other languages.

For server side applications, the ability to move applications from Windows to Linux to BSD is nice. Scala gives you that while C++ requires a recompile for each platform with a mess of #ifdef and Make options.

Scala has tuples, traits (similar to Ruby mixins, and a very nice solution to Java's lack of multiple inheritance and C++'s multiple inheritance headaches), cases classes that are far more powerful than the C++ switch or other similar C++ constructs (or at least, all of the ones I've encountered), functional language constructs (which in many cases use compile-time tail call optimization to keep run time performance acceptable), and the ability to easily import and use existing Java APIs and libraries and run on existing Java servlet containers. Check out the Scala web development platform lift ( http://liftweb.net/ ) - the example website has a staggering number of features for such a tiny codebase.

Re:Strongly typed language?

[Abcd1234]

Because objects are typed. What would the result be in weakly typed language like C where you do 1 + "1234"?

Probably a warning that you're adding an integer to a pointer, resulting in a pointer result. It's still doing coercion. Worse, it's not at all what you'd expect unless you know the niggly fact that, in C, strings == arrays == pointers.

Um, that's part of the definition I gave as a distinction between statically typed languages and strongly typed languages.

And it's incorrect. Statically typed languages do whatever they do with their types primarily at compile-time. In fact, in many cases, the types could just as easily disappear at run-time, as happens in the case of C (although they don't always... Java, for example, is statically typed, but it retains some of that typing information at run-time so that it can enforce type constraints when casts are performed).

Additionally, and this goes to your claim, a statically-typed language absolutely *can* do automatic type coercion, as does C, for example, by automatically converting floats to ints and vice versa.

In short, static/dynamic and strong/weak typing are 100% orthogonal concepts, and to conflate them is a mistake.

Strong typing != static typing. Period.

Of course. As I say, they're entirely orthogonal. Comparing them doesn't even make sense. So why are you doing it?

Re:Strongly typed language?

[mcvos]

Weird casting issues? Maybe your design sucks.

And that of just about every Java library out there. There are a lot of great Java libraries that do lots of wonderful things, but mostly they do a lot of work to negate the advatages of static typing. Working with Java will eventually convince you that dynamic typing is the way to go.

Re:Strongly typed language?

[mcvos]

What would the result be in weakly typed language like C where you do 1 + "1234"?

My guess would be it's the memory location where the "2" from that string is stored.

See, C, while superficially weakly typed, is actually a strongly typed language where every object is a memory location. At least that's how I managed to get somebody to finally understand C's pointer arithmatic.

Re:Strongly typed language?

[DuckDodgers]

Can't you do weak type casts in C++?

Re:Oooooooohhhh....

[DuckDodgers]

Hey, I'd love to program for fun. But I have to put food on the table. The honeymoon I had with Java is long over, but since I'm making twice as much as I did as a C developer, I'm going to stay with it.

If I could find a company local that would pay me as much, or nearly as much, to work on Scala or Haskell, I would jump ship in a hurry. Until then, I'm not going anywhere.

Re:Strongly typed language?

[e4g4]

Astounding - an appropriate and accurate car analogy on Slashdot, for once.

Hats off to you, sir!

Re:Reinventing the wheel is sometimes good

[Ichoran]

Ruby can be made a lot more terse than Scala can but at that point it's quite difficult to read. I've tried to match the terseness of a number of very compact Ruby programs in Scala and I'm lucky to get within 50%.

At the same level of terseness (maximum Scala terseness, comfortable Ruby terseness), Ruby is easier to read unless you're much more familiar with Scala than Ruby. (Stuff like _._2 < _ in Scala takes a while to figure out, and even when you've got it it takes a bit of thinking.)

At a comfortable level in both languages, I find Scala easier to read but less terse--the key being mostly Scala's descriptive inline operators.

Re:Scalability claims are bogus

[Ichoran]

The JVM scales nicely, but you can load stuff on top of it that makes it not scale nicely.

That the Scala folks were careful to let the JVM scale nicely is a credit to them.

(Plus, the scalability also refers to the types of modularity that are available--Scala allows good practice in that area also.)

No thank you

[ZmeiGorynych]

Erm, I can't think of _any_ situation in applied programming where C++ is a good idea (I design medium to high frequency automated trading algos for a major bank, well run a small team that does that). 90% of the time something like jython or matlab is fast enough and a hell of a lot easier to write and debug, and doesn't give you nearly the amount of options to cut your limbs off by chance - and the 10% of performance bottlenecks can be handled by C/Fortran snippets.

I am aware that many coders seem to think the very messiness of C++ (several languages crunched into one, but not really in a consistent or compatible manner) is somehow an advantage (trying to call C++ DLLs from other languages, oh my god what a pain, tripled if you want it to work on both windows and Linux), but I'd rather fill my brain with domain-specific knowledge and not with language-specific trivia (eg valarray copy semantics are not compatible with STL, but the code using vector<valarray<> > only actually breaks under gcc and works under VC++; and so on and so forth - why the fuck should I care?).

I was in the "C++ is great" camp for a couple of years and filled my head with all those stupid quirks (local typedefs in recursive templated classes, oh what fun) , but at one point realized I just couldn't be bothered. Even Java, as crippled as it is language-wise, is IMO preferable to C++, because once it compiles, you can just use the jar, no linker issues, no memory corruption - and if I do need to manage my memory in a bottleneck, a C snippet will do just fine.

And if I can keep using the JVM but one day switch from Java to a less crippled language, maybe Scala, that's the best of all worlds.

Re:Reinventing the wheel is sometimes good

[mcvos]

Thanks! I'd mod you informative if I could.

Re:Strongly typed language?

[SL Baur]

What would the result be in weakly typed language like C where you do 1 + "1234"?

My guess would be it's the memory location where the "2" from that string is stored.

Correct.

Re:Reinventing the wheel is sometimes good

[SL Baur]

At a comfortable level in both languages, I find Scala easier to read but less terse--the key being mostly Scala's descriptive inline operators.

That's probably the correct level of abstraction to think about it. Repeated sequences of anything are going to be mind numbing. Shorter sequences are going to be easier to grasp at first sight. But only on average and the 4-letter P-word has certainly proved that very short code isn't necessarily readable or maintainable.

Re:Reinventing the wheel is sometimes good

[Vintermann]

My Perl colleagues are swooning at Moose. It certainly seems like something to take note of, if you're into that sort of thing (Perl, that is).

Re:Reinventing the wheel is sometimes good

[CarpetShark]

yes, the similarity is immediately obvious

I know.

http://www.kichwa.com/quik_ref/spec_variables.html

http://www.perl.com/doc/manual/html/pod/perlop.html

Re:Strongly typed language?

[angel'o'sphere]

Can you explain why JavaScript is weakly typed? I allways was of the impression it is strong typed.

angel'o'sphere

Re:Reinventing the wheel is sometimes good

[DuckDodgers]

I've read that, aside from startup times, the JVM is extremely fast these days. But I thought most well-written Java (and by extension, Scala) applications are still 2-10 times slower than equivalent C.