Which language is the least bad?

blakeyrat

@gąska said in Which language is the least bad?:

Sounds like Java. Guess what - Java took most of the C++'s market share back in late 90s/early 00s. But couldn't take it all - because generics and value semantics.

More likely because Java didn't have any GUI libraries that weren't absolute garbage.

Gąska

@blakeyrat are you saying C++ used to have half decent GUI libraries before 2007? Because it certainly didn't after that.

blakeyrat

@scholrlea said in Which language is the least bad?:

Lists are an ADT;

A home automation and security company?

Sorry, I Googled this but literally the only thing that came up was the security company.

@scholrlea said in Which language is the least bad?:

a chain of CONS cells

Uh. Same deal.

blakeyrat

@gąska I don't know if it does or not. I just know that GUI apps written in C++ were universally better and obviously superior to Java GUI apps for a very, very, very long time. (Possibly not now. But probably still yes.)

C++ might be equally "bad", but if the end-result is better, that's what you'd pick.

Gąska

@blakeyrat said in Which language is the least bad?:

Sorry, I Googled this but literally the only thing that came up was the security company.

You must work on your googling skills. Tip: when you're googling for programming-related stuff, add "programming" to your query.

blakeyrat

@gąska How about "when communicating with other people on a forum, DEFINE YOUR FUCKING OBSCURE ACRONYMS YOU ASSHOLE!" I mean the point to posting here is to communicate, right? So fucking communicate.

It's hard enough to read random LISP rantings without having to keep searching for vague shit in another window.

ScholRLEA

@blakeyrat said in Which language is the least bad?:

@gąska How about "when communicating with other people on a forum, DEFINE YOUR FUCKING OBSCURE ACRONYMS YOU ASSHOLE!" I mean the point to posting here is to communicate, right?

I'm sorry, I thought you would be able to recognize a term you yourself have used before. Are you honestly going to tell me that most programmers won't be able able to resolve 'Abstract Data Type' from that in this context?

As for 'Cons cell', I'll give you that, it's pretty much a Lisp term. However, since the point was that it wasn't a relevant detail, I fail to see why you would need to understand it.

Gąska

@blakeyrat how about "when inserting yourself in others' discussions, DON'T EXPECT POSTS NOT DIRECTED AT YOU TO ACCOMODATE YOURSELF YOU ASSHOLE!"

blakeyrat

@scholrlea said in Which language is the least bad?:

I'm sorry, I thought you would be able to recognize a term you yourself have used before.

I don't recall ever typing "ADT" except when talking about the security company. But, sure, why not, I'll take your word for it.

@scholrlea said in Which language is the least bad?:

Are you honestly going to tell me that most programmers won't be able able to resolve 'Abstract Data Type' from that in this context?

I actually thought it was that acyclic directed whatever that Git fans are always so excited about.

I don't know what "most programmers" would think ADT meant, but I didn't get it. I can virtually guarantee I've never heard an abstract data type referred to as an "ADT" before.

I still don't know what a "CONS cell" is.

@gąska said in Which language is the least bad?:

how about "wh

Blah blah, point is I don't get why someone would post something on a forum with the intent, presumably, of communicating some idea to them but then not include enough information for the reader to figure out what the idea is. But sure, I'm the idiot.

boomzilla

@gąska said in Which language is the least bad?:

@blakeyrat are you saying C++ used to have half decent GUI libraries before 2007? Because it certainly didn't after that.

It just (generally) used whatever was native. That's not what Java did, and interfacing with native stuff is and was a PITA with java.

Gąska

@blakeyrat said in Which language is the least bad?:

Blah blah, point is I don't get why someone would post something on a forum with the intent, presumably, of communicating some idea to them but then not include enough information for the reader to figure out what the idea is. But sure, I'm the idiot.

I did figure it out. So don't dismiss the idiot hypothesis outright.

masonwheeler

@scholrlea said in Which language is the least bad?:

Seriously, when was the last time you saw a language such as Python implement (for example) lists in a sensible way? Lists are an ADT; just because the obvious way to implement them is a linked list doesn't mean that they need to be implemented that way.

The obvious way to implement lists is an an array-backed list. Linked lists aren't obvious at all; they make all of the common list operations (add-to-end, insert-at-index, iterate, read-at-index) more complicated and less efficient; about the only place where they're arguably easier is the delete operation, which is far less common.

In fact, I'd go so far as to say that linked lists are a premature optimization. It's a concept which made a lot of sense in the specific context of the sort of hardware constraints we saw decades ago, but today it's exceptionally rare to find a use case where linked-list semantics rather than array-list semantics are the best tool for the job.

The problem then, of course, is that you don't get the control over the form the data structure takes in memory; but let's be honest here, how often is that really needed for anything other than systems programming?

Ask a game developer sometime. Or a compiler engineer. Or someone writing a LOB application that deals with building reports out of tens or hundreds of thousands of records. Or... well, you get the point. Let's be honest here, performance is a feature.

heterodox

@blakeyrat said in Which language is the least bad?:

I actually thought it was that acyclic directed whatever that Git fans are always so excited about.

That's a DAG (directed acyclic graph). :D

I don't know what "most programmers" would think ADT meant, but I didn't get it. I can virtually guarantee I've never heard an abstract data type referred to as an "ADT" before.

I have, but never outside academia.

masonwheeler

@gąska said in Which language is the least bad?:

That's probably the main reason of popularity. But that aside, value semantics are very nice to have for other reasons than performance. With value semantics, when I have an object, it's mine. Unless I give away pointers to it, no one can change it. When I copy an object, it's a copy; an independent object I can do whatever I want with and it won't affect the original (unless it's supposed to - but I have control over when it does and when it doesn't, and it doesn't by default).

And how often do you actually want to copy an object?

Also, languages with reference semantics often don't offer references to references, which was really annoying in data structures classes at uni - I've had to use wrapper objects for all my data, since generic "swap" function isn't provided by Java and it's impossible to implement yourself.

See "Java is flawed; C# fixed a lot of its problems" above.

masonwheeler

@blakeyrat said in Which language is the least bad?:

@scholrlea said in Which language is the least bad?:

Lists are an ADT;

A home automation and security company?

Sorry, I Googled this but literally the only thing that came up was the security company.

Abstract Data Type.

Out of curiosity, did you take any CS classes in college? This is 100-level material.

@scholrlea said in Which language is the least bad?:

a chain of CONS cells

Uh. Same deal.

A very Lispy way to say "linked list elements." Essentially a CONS cell is a data type that contains two elements: a value and a pointer to the next CONS cell, which might be null.

masonwheeler

@heterodox said in Which language is the least bad?:

I have, but never outside academia.

Seriously?

Gąska

@masonwheeler said in Which language is the least bad?:

@gąska said in Which language is the least bad?:

That's probably the main reason of popularity. But that aside, value semantics are very nice to have for other reasons than performance. With value semantics, when I have an object, it's mine. Unless I give away pointers to it, no one can change it. When I copy an object, it's a copy; an independent object I can do whatever I want with and it won't affect the original (unless it's supposed to - but I have control over when it does and when it doesn't, and it doesn't by default).

And how often do you actually want to copy an object?

All the time. But it might be because I use objects as values, not glorified function pointers.

Also, languages with reference semantics often don't offer references to references, which was really annoying in data structures classes at uni - I've had to use wrapper objects for all my data, since generic "swap" function isn't provided by Java and it's impossible to implement yourself.

See "Java is flawed; C# fixed a lot of its problems" above.

It's way too above for me to see. But either way, C# only allows references to references in very limited contexts. Helps a lot, but still not the full feature.

heterodox

@masonwheeler said in Which language is the least bad?:

Seriously?

No, I was making a very obscure joke.

Of course I'm serious. Repeat after me:

My experience may not be your experience.
Your mileage may vary.
This tofurkey may contain tree nuts.

masonwheeler

@gąska said in Which language is the least bad?:

All the time. But it might be because I use objects as values

If you're using objects as values, then stop using objects and use structs.

not glorified function pointers.

...do you even OOP, bro? That makes no sense at all. (Unless you're in Java, which ~~doesn't~~for a long time didn't have delegates and therefore ~~has~~had to implement function pointers as really bulky, cumbersome objects that implement an interface with a single method.)

It's way too above for me to see. But either way, C# only allows references to references in very limited contexts. Helps a lot, but still not the full feature.

Mind giving a use case, then? Because the one you gave, about being unable to implement a swap function in Java, has been available in C# since day 1 with ref parameters.

Gąska

@masonwheeler said in Which language is the least bad?:

@gąska said in Which language is the least bad?:

All the time. But it might be because I use objects as values

If you're using objects as values, then stop using objects and use structs.

C# is the only language where that sentence makes even a lick of sense. And I mostly code in languages that aren't C#. Even in C#, there are situation where I must - or just prefer - to use classes instead of structs. Generics come to mind.

not glorified function pointers.

...do you even OOP, bro? That makes no sense at all.

At the most basic level, objects are a bunch of member fields and a bunch of methods. If you focus on the member fields part, you end up with value objects. If you don't want value objects, it means you mostly focus on the methods part - and then objects and inheritance becomes an easy way to juggle various implementations of the same interface at runtime. They become a very nice abstraction over vtables, which are essentially arrays of function pointers.

@masonwheeler said in Which language is the least bad?:

It's way too above for me to see. But either way, C# only allows references to references in very limited contexts. Helps a lot, but still not the full feature.

Mind giving a use case, then? Because the one you gave, about being unable to implement a swap function in Java, has been available in C# since day 1 with ref parameters.

Traversing linked list and doing some funny things. A local variable of type pointer-to-pointer-to-node is very convenient for updating next pointers of nodes you've already passed.

masonwheeler

@gąska said in Which language is the least bad?:

C# is the only language where that sentence makes even a lick of sense.

I see you've never used Delphi...

And I mostly code in languages that aren't C#. Even in C#, there are situation where I must - or just prefer - to use classes instead of structs. Generics come to mind.

You can put generics in struts.

At the most basic level, objects are a bunch of member fields and a bunch of methods. If you focus on the member fields part, you end up with value objects. If you don't want value objects, it means you mostly focus on the methods part - and then objects and inheritance becomes an easy way to juggle various implementations of the same interface at runtime. They become a very nice abstraction over vtables, which are essentially arrays of function pointers.

At the most basic level, all code and data is essentially a bunch of 1s and 0s. This doesn't mean that's a useful way to think about it 99% of the time.

There are basically two ways to look at objects: as PODOs (plain old data objects; third letter is frequently replaced with something indicative of the language you're using) which are simple data holders with minimal or no methods, and as "business objects," objects that combine state with methods that know how to deal with the data.

This is something completely different from "mostly focusing on the methods part." That's closures. (AKA delegates, AKA lambdas, AKA anonymous methods, AKA the thing Java had no non-horrible way of doing for the longest time.) Closures are functions that drag a bit of state data along for the ride. Business objects are about thinking of the data and its associated behavior as a unified whole.

Traversing linked list

See "linked lists are ," above.

and doing some funny things. A local variable of type pointer-to-pointer-to-node is very convenient for updating next pointers of nodes you've already passed.

So what you want is local variables of type ref <whatever>? C# has that now. (It's very recent, from the newest version I think, but it's there.)

TwelveBaud

@masonwheeler said in Which language is the least bad?:

(Unless you're in Java, which for a long time didn't have delegates and therefore had to implement function pointers as really bulky, cumbersome objects that implement an interface with a single method.)

Still doesn't. When you make a lambda it makes an anonymous class that extends Runnable or whatever for you behind the scenes.

pie_flavor

@twelvebaud It does do it efficiently, though. More efficiently than an actual anonymous class would be.

blakeyrat

@masonwheeler said in Which language is the least bad?:

Abstract Data Type.
Out of curiosity, did you take any CS classes in college? This is 100-level material.

Jesus Christ, you people.

I know what an abstract data type is. I did not know what an "ADT" was. If he had typed abstract data type, I would have of course not bother posting that request for clarification. I've never before in my life seen someone type "ADT" to mean "abstract data type".

masonwheeler

@twelvebaud Well yeah, that's the way it has to work--there's really no difference between an object and a closure; they're both state data and functions that operate on it bound together in a single entity, with the distinction lying entirely in which aspect you're more focused on--but at least the language does it for you now instead of the developer having to do the whole thing manually.

masonwheeler

@blakeyrat said in Which language is the least bad?:

I know what an abstract data type is. I did not know what an "ADT" was. If he had typed abstract data type, I would have of course not bother posting that request for clarification. I've never before in my life seen someone type "ADT" to mean "abstract data type".

Well, I can't be the only one around here who sees people use the term on a somewhat regular basis... can I?

blakeyrat

@masonwheeler Maybe it's me. I usually avoid this kind of technical wankery, as I'm more interested in writing software.

masonwheeler

@blakeyrat That's... a very odd perspective. I devour stuff like that, because I'm interested in writing software, and writing software is a very technical subject that requires a solid theoretical foundation to do well.

blakeyrat

@masonwheeler Nope. It requires empathy for the user, deep knowledge of the problem space, an eye for UX, a holistic understanding of the business need, data modeling, etc.

The actual code is the boring bit you only do so you can get to the interesting stuff.

People who write software because "they like coding" almost invariably produce garbage.

Gąska

@masonwheeler said in Which language is the least bad?:

@gąska said in Which language is the least bad?:

C# is the only language where that sentence makes even a lick of sense.

I see you've never used Delphi...

And I thank God everyday for that. Anyway, my point is that many languages don't have structs or anything that behaves like C# structs, and in C++ structs are synonymous to classes, so your tip "use structs not objects" is very language-specific.

And I mostly code in languages that aren't C#. Even in C#, there are situation where I must - or just prefer - to use classes instead of structs. Generics come to mind.

You can put generics in struts.

I meant writing generics. You cannot make a function generic over both classes and structs if you want to use null.

At the most basic level, objects are a bunch of member fields and a bunch of methods. If you focus on the member fields part, you end up with value objects. If you don't want value objects, it means you mostly focus on the methods part - and then objects and inheritance becomes an easy way to juggle various implementations of the same interface at runtime. They become a very nice abstraction over vtables, which are essentially arrays of function pointers.

At the most basic level, all code and data is essentially a bunch of 1s and 0s. This doesn't mean that's a useful way to think about it 99% of the time.

Function pointer is a useful way to think about objects 99% of the time. Not the most useful, but it doesn't constrain you too much. It's like Data-Oriented Design, except with code instead of data.

There are basically two ways to look at objects: as PODOs (plain old data objects; third letter is frequently replaced with something indicative of the language you're using) which are simple data holders with minimal or no methods, and as "business objects," objects that combine state with methods that know how to deal with the data.

No, that's not ways to look at objects. It's a way to design a particular object. It's not an alternative perspective of the same entity. It's a different entity for different purpose. You can't interpret business objects as PODOs. You can interpret business objects as data+vtable.

This is something completely different from "mostly focusing on the methods part." That's closures. (AKA delegates, AKA lambdas, AKA anonymous methods, AKA the thing Java had no non-horrible way of doing for the longest time.)

I meant more like factories (which are hot-swappable bunches of constructors), services (which are hot-swappable bunches of functions) and similar design patters where the main point is that different objects can do different things on same method calls, but from caller's perspective there's no difference in their behavior. It has nothing to do with functional programming.

Traversing linked list

See "linked lists are ," above.

Agreed. Nevertheless, linked lists are ubiquitous in legacy code of all kinds. Kernel programmers are especially fond of them. So being able to deal with them nicely is definitely a plus for a programming language.

and doing some funny things. A local variable of type pointer-to-pointer-to-node is very convenient for updating next pointers of nodes you've already passed.

So what you want is local variables of type ref <whatever>? C# has that now. (It's very recent, from the newest version I think, but it's there.)

I've just read a documentation for it and didn't understand a word. But if you're saying this solves this particular problem, I'm gonna believe you. Good for us!

Gąska

@blakeyrat said in Which language is the least bad?:

@masonwheeler Maybe it's me. I usually avoid this kind of technical wankery, as I'm more interested in writing software.

I wish you avoided them more.

ScholRLEA

@masonwheeler said in Which language is the least bad?:

@scholrlea said in Which language is the least bad?:

Seriously, when was the last time you saw a language such as Python implement (for example) lists in a sensible way? Lists are an ADT; just because the obvious way to implement them is a linked list doesn't mean that they need to be implemented that way.

The obvious way to implement lists is an an array-backed list. Linked lists aren't obvious at all; they make all of the common list operations (add-to-end, insert-at-index, iterate, read-at-index) more complicated and less efficient; about the only place where they're arguably easier is the delete operation, which is far less common.

In fact, I'd go so far as to say that linked lists are a premature optimization. It's a concept which made a lot of sense in the specific context of the sort of hardware constraints we saw decades ago, but today it's exceptionally rare to find a use case where linked-list semantics rather than array-list semantics are the best tool for the job.

I am pretty sure we are violently agreeing, here. My whole point was that a linked list is a naïve implementation of a list, one which would seem the 'obvious' choice to, say, a second-year student who just got burned by trying to use a 'big enough' array. It's something most novice programmers learn early on, but it is rarely if the most sensible solution.

My point was that just because a Cons cell (or pair - it is actually a pair of untyped pointers, semantically, though again, most implementations snap pointers on small scalar values by putting the value in that field with a type tag to let you know it isn't a pointer) is, semantically, a linked list, doesn't mean that it has to be implemented as such, and usually shouldn't be.

The problem then, of course, is that you don't get the control over the form the data structure takes in memory; but let's be honest here, how often is that really needed for anything other than systems programming?

Ask a game developer sometime. Or a compiler engineer. Or someone writing a LOB application that deals with building reports out of tens or hundreds of thousands of records. Or... well, you get the point. Let's be honest here, performance is a feature.

I am not saying such cases don't exist. They come up from time to time with any kind of programming. However, it is also the case that even for those programmers who need them most often, the times when you absolutely need it are the exceptions rather than the rule.

What I am advocating is a development system - of which the language and the libraries would only be a part - which allows the developers to say either in code or during compilation, "This is the default behavior I want from the (compiler|linker|library implementation) for this part of the program; if I need something else, I will tell you". My target is flexibility, but as we all know, flexibility is hard.

If it helps any, you can think of it as a generalization of the idea behind the abstract factory pattern: the 'factory' (which in this case would the library plus the compiler) can have several different implementations available, and you as a programmer can add new ones if you need to. You can either let the tools select one that it thinks fits best based on some analysis, or request that it use a specific one, whether forcefully ("I absolutely need this particular memory layout, do it or give me an error if you can't") or as a suggestion ("let's see, I expect that algorithms A, B, and C would work well here, prioritize your analysis on those").

This also, in my mind, goes hand in hand with the idea of allowing these requirements be placed out of band; the goal is to let you focus on the design, and then define how to tune to the implementation after the fact, once you know it works. While there's no way you can tune the performance for everything without hand-massaging it, a 90% or even 75% solution that reduces the need for changes in the code would be a big step forward IMAO.

And yes, I know that not everything you would need a fixed implementation for is performance related; it certainly comes up in things like fields for device registers or GDTs and so forth. But again, the idea is that need to balance that need with the goals of understandable code and reasonable development times, rather than throwing the baby out with the bathwater by either embracing (for example, and going back to the original point) value types as the default when they are only need infrequently, or conversely, not allowing value types on request.

I'll get back to @Gąska's points later.

masonwheeler

@scholrlea said in Which language is the least bad?:

I am not saying such cases don't exist. They come up from time to time with any kind of programming. However, it is also the case that even for those programmers who need them most often, the times when you absolutely need it are the exceptions rather than the rule.

True, but they're common enough exceptions that they may as well be their own rule. In other words, it's critical to have support for them instead of just saying "oh, we're going to abstract all that away with high-level rainbows and sparkles and you don't need to worry your pretty little head about the details and so we won't give you a way to do so."

What I am advocating is a development system - of which the language and the libraries would only be a part - which allows the developers to say ahead, "This is the default behavior I want from the (compiler|linker|library implementation) for this part of the program; if I need something else, I will tell you".

That sounds a lot like having multiple implementations of the same basic interface/abstract class available, and choosing one or the other... except more complicated. What's the advantage of doing it that way?

If it helps any, you can think of it as a generalization of the idea being the abstract factory pattern: the 'factory' (which in this case would the library plus the compiler) can have several different implementations available, and you as a programmer can add new ones if you need to. You can either let the tools select one that it thinks fits best based on some analysis, or request that it use a specific one, either forcefully ("I absolutely need this particular memory layout, do it or give me an error if you can't") or as a suggestion ("let's see, I expect that algorithms A, B, and C would work well here, prioritize your analysis on those").

So you're talking about metaprogramming, or...?

heterodox

@masonwheeler said in Which language is the least bad?:

Well, I can't be the only one around here who sees people use the term on a somewhat regular basis... can I?

Maybe, maybe not. Signs seem to point to yes. I work in a sector that's legendary for its acronyms and yet I still try to avoid them; they just cause meetings like the one I had today where everyone was using the same acronyms, even had the same expansions for them, but different agencies seemed to be using totally different definitions for them within the scope of a project timeline.

If you gotta use them, it actually saves time to define them upfront the first time, otherwise you run the risk of many rounds of clarification (or many posts calling each other ignorant).

Edit: Also, it seems to me that if you've worked with programming languages (e.g. Boo), you're more likely to know these things off the top of your head vs. someone who's an application developer.

ScholRLEA

@masonwheeler Yes, I am talking about meta-programming. Sorry if I wasn't being clear on that.

boomzilla

@masonwheeler said in Which language is the least bad?:

This is something completely different from "mostly focusing on the methods part." That's closures. (AKA delegates, AKA lambdas, AKA anonymous methods, AKA the thing Java had no non-horrible way of doing for the longest time.)

I don't get the hate for this. Defining a separate private class or something to instantiate and pass is usually clearer for me to read than shoving it all inline.

boomzilla

@blakeyrat said in Which language is the least bad?:

@masonwheeler Maybe it's me. I usually avoid this kind of technical wankery, as I'm more interested in writing software.

It's not just you. He has difficulty relating to people with different experiences than him. I can't imagine why you guys don't get along.

masonwheeler

@boomzilla said in Which language is the least bad?:

I don't get the hate for this. Defining a separate private class or something to instantiate and pass is usually clearer for me to read than shoving it all inline.

Generally because most of the time when you need one, the actual logic you care about is a one-liner, and so having the compiler take care of it brings two benefits:

No having to write up an entire class to express a single line of logic
No having to put the one-off bit of logic somewhere other than where it's used. It's more clear because it's closer together.

boomzilla

@masonwheeler said in Which language is the least bad?:

@boomzilla said in Which language is the least bad?:

I don't get the hate for this. Defining a separate private class or something to instantiate and pass is usually clearer for me to read than shoving it all inline.

Generally because most of the time when you need one, the actual logic you care about is a one-liner, and so having the compiler take care of it brings two benefits:

No having to write up an entire class to express a single line of logic

No having to put the one-off bit of logic somewhere other than where it's used. It's more clear because it's closer together.

Yeah, but OTOH, you're cluttering things up that could be much cleaner with the extra abstraction, like refactoring something out to a separate method (which is...almost exactly what this is, actually).

I think it's more about people being lazy and just wanting to put everything right there.

masonwheeler

@boomzilla said in Which language is the least bad?:

I think it's more about people being lazy

...and you're not in favor of this?

boomzilla

@masonwheeler said in Which language is the least bad?:

@boomzilla said in Which language is the least bad?:

I think it's more about people being lazy

...and you're not in favor of this?

I am when it makes their code more difficult for me to read.

masonwheeler

@boomzilla This is the part I don't get. Are you honestly saying that this:

List<int> GetValues(List<Foo> myList) {
    return myList.Select(element => element.Value).ToList();
}

is more difficult to read than this:

private int ValueSelector(Foo element) {
    return element.Value;
}

List<int> GetValues(List<Foo> myList) {
    return myList.Select(ValueSelector).ToList();
}

or this?

private class ValueSelector {
       int Run(Foo element) {
        return element.Value;
    }
}

List<int> GetValues(List<Foo> myList) {
    return myList.Select(new ValueSelector().Run).ToList();
}

boomzilla

@masonwheeler Honestly, none of that makes much sense to me. I suspect that's LINQ? It's much simpler than the sort of stuff I'm used to (which is mostly comparators, which can often be several lines, easily).

masonwheeler

@boomzilla Yes, it's LINQ, one of the most common use cases for inline lambdas.

And yeah, when you're using large functions it is often better to put it in its own method, but a lot of the time you don't need to, and the extra plumbing is cumbersome and distracting.

I do both styles, as appropriate. Right tool for the job and all that.

pie_flavor

@boomzilla 'kids these days with their sensible programming constructs'

boomzilla

@masonwheeler said in Which language is the least bad?:

Yes, it's LINQ, one of the most common use cases for inline lambdas.

Sorry, I can't really get past the weird (to me) syntax of that.

ES6 and its arrows don't feel right, either.

masonwheeler

@boomzilla In Boo, I'd do it like so:

def GetValues(myList as List of Foo) as List of int:
    return myList.Select({element | element.Value}).ToList()

Does that look any less weird? :P

pie_flavor

@masonwheeler Not in the least. I can get over the strangeness with lambdas, but List of Foo and List of int? If you want to be a special snowflake, use brackets. Or parentheses. Or put the types before. But never put the generic types after a keyword instead of within delimiters.

ScholRLEA

@pie_flavor Dr. Wirth would like a word with you..

masonwheeler

@pie_flavor You could also say List[of int], and it's syntactically required if there's more than one type parameter. I just find it cleaner to leave that off when there's only one.