Porting the Go compiler to Go

Posted May 8, 2014 2:32 UTC (Thu) by cmccabe (guest, #60281)
In reply to: Porting the Go compiler to Go by Cyberax
Parent article: Porting the Go compiler to Go

> And no multimaps. So if you need to do one step away from
> built-in constructs - you're on your own.

You can just have a map from the key to a list of values to get the functionality of a multimap.

Before you start talking about other data structures, it's obvious that C++-style generics are good for containers. Nobody is disputing that. So feel free to attack that windmill all you like. Meanwhile, the real point I made, which is that most programmers don't need new and exotic containers most of the time, remains unaddressed.

> Sloppiness does not excuse poor language design.

Was anyone here arguing that sloppiness excused poor language design? Or are you just arguing against an imaginary opponent?

I am frustrated that you did not reply to my actual argument, which is that different languages fill different roles. The fact that you can't understand why people use PHP rather than your favorite programming languages (C++?) indicates that you still don't get it. There is a niche for a simple language with a short learning curve, with a lot of functionality built-in. We can all agree that PHP is not a great language (even when used for what it's good at), but the fact that it continues to exist is living proof that the stuff you care about isn't as important as you think. In the real world, different languages fill different roles. There will never be one language to rule them all, because there is not one use case to rule them all.

There are lots of languages out there with all the stuff you like. Haskell, Scala, and SML come to mind. How about using them and explaining to us why they're so great for our use-cases? That would be a nice contribution. Don't be negative about something you don't even use.

Porting the Go compiler to Go

Posted May 8, 2014 3:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> You can just have a map from the key to a list of values to get the functionality of a multimap.
Sure, but it's awkward. Each addition now must check that a value exists and add a new list if it doesn't. _AND_ you can't write a generic helper function to do it.

> Meanwhile, the real point I made, which is that most programmers don't need new and exotic containers most of the time, remains unaddressed.
They do. They might not _know_ it, but multimaps make a lot of code look cleaner. And the amount of interface{} casting in any Go program is just downright embarrassing.

> Was anyone here arguing that sloppiness excused poor language design? Or are you just arguing against an imaginary opponent?
Well, you seem to argue that ability to allow sloppy code now and then (well, very often in fact) excuses the poor language design. And that a convenient form (look Ma, just one binary!) trumps other considerations.

That's the argument that led to PHP. It also allowed easy-to-install environment (without those darned CLASSPATHs) and also advertised itself as a 'practical' language. After all, what programmers might want to use classes when you have this nice MySQL interface?

Porting the Go compiler to Go

Posted May 14, 2014 1:21 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> Meanwhile, the real point I made, which is that most programmers don't need new and exotic containers most of the time, remains unaddressed.
This “generics are only about containers“ thing is utterly stupid. Trivial abstractions like map, fold, filter, function composition etc. need generics to express them properly, and they're needed for futures, composable stream abstractions, parser combinators, on and on it goes…