[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]

λ - programming

/lam/bda /lam/bda duck
Name
Email
Subject
Comment
File
Password (For file deletion.)

BUY LAINCHAN STICKERS HERE

STREAM » LainTV « STREAM

[Return][Go to bottom]

File: 1434539907934.png (52.88 KB, 383x383, gophercolor.png) ImgOps iqdb

 No.6735[View All]

What do you think about golang? I've started learnig it and it looks good to me so far.
88 posts and 8 image replies omitted. Click reply to view.
>>

 No.11422

>>11420
yeah definitely, I saw the chapter preview earlier ITT.

>>

 No.11444

>>11151
Gj grasping at straws:
>Java/C++/whatever
You forgot to notice the last option, highlighting the fact that there's plenty other languages than Java, C++ and Go.

Go is not expressive, not rich in features, not popular outside of Google and Piketard circles, and as a sytems language it's substandard.
>easier to understand
Literally the only thing it has going for it, and is by no means the only contender when it comes to ease of understanding.
>more maintainable than c++
Whoop de fuarrrking do, it's better than C++ at something, someone bring in the medal! C++ is notorious as a jack of all trades, master of none (emphasis on "master of none" here), so any language is better than C++ in some way or another.

>>

 No.11445

Here's an article that does a good job at explaining why Go is so popular these days:
https://honza.ca/2015/11/language-choice

>>

 No.11446

>>11444 Go's actually getting really popular in the world of scalable services because of it produces fast and deployable apps with web functionality builtin. As a language in that space it has serious potential to be huge in the next few years (and we're even seeing it now to an extent) and that's a serious thing. That's a big deal and a serious plus for the language in the long term.

>>11157 How in Lain's name is Go anything like Java? Go's barely a member of the C syntax family and it's focused on concurrency instead of events. The garbage collector is also fast instead of intrusive and historically annoying, and it produces standalone statically linked binaries, the opposite of what Java produces??

>>

 No.11453

>>11446
>Go's actually getting really popular in the world of scalable services because of it produces fast and deployable apps with web functionality builtin. As a language in that space it has serious potential to be huge in the next few years (and we're even seeing it now to an extent) and that's a serious thing. That's a big deal and a serious plus for the language in the long term.
Stop. Read what you have written. It's just buzz words and appeals to popularity. Any language can be used to produce fast and deployable apps with web functionality, whatever that means, and Go doesn't make it any easier. A question to ponder; if Go is so easy to learn why is it so very important that I learn it now?

>>

 No.11455

>>11446
>How in Lain's name is Go anything like Java? Go's barely a member of the C syntax family and it's focused on concurrency instead of events. The garbage collector is also fast instead of intrusive and historically annoying, and it produces standalone statically linked binaries, the opposite of what Java produces??
Go is like Java because it most definitely is a member of the C syntax[0], it is being pushed by a large company, and it prioritizes interchangeable software engineers over abstractions. "Go is efficient, scalable, and productive. Some programmers find it fun to work in; others find it unimaginative, even boring. In this article we will explain why those are not contradictory positions. Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects."[1]

[0] https://golang.org/doc/faq#ancestors
[1] https://talks.golang.org/2012/splash.article

>>

 No.11458

>>11455
I think he meant that it's not like Java in the sense that it's a terrible language.

>>

 No.11460

>>11453
It isn't important that you learn it now or if you even learn it at all. I apologise if I accidentally implied that in my response. It's a simple language, there's no stress. But it is becoming popular for the reasons that I outlined, and if you don't believe me look at it's adoption at bigger companies, the New York Times (https://www.youtube.com/watch?v=bAQ9ShmXYLY), Dropbox (https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-libraries/) and the BBC (https://blog.golang.org/go-turns-three) immediately spring to mind for me. You can even read a list here (https://github.com/golang/go/wiki/GoUsers). While the fact that a string of companies using a developing language should be nothing surprising, a common theme across the board of their use is how each of these companies produce services that need to scale that handle thousands of requests a day. That speaks for itself. It's a fact that Go's fast (https://blog.golang.org/go15gc) and that concurrency goes hand in hand with distributed services design and that's a major feature and pattern of Go.

>>11455
The syntax features similarities with C that the Go team does acknowledge, but it is still a language that is on the fringe.
The developers list the syntax as being inspired by C here but that doesn't necessarily mean that it is a part of it of the language family. And even still, is the language like Java because of it's similarities in syntax? It's very different at a design and implementation level. I mentioned in my reply that you responded to that the language is prominent in distributed services. That is of Google's interest, and they state in the block that you quoted that they designed the language with their needs in mind.

>>

 No.11468

"go" away.

>>

 No.11470

>>11151
>Go is much saner, easier to understand and more maintainable than c++.
I agree with that, but you do not mention its simpleness. It's easy, that is good, but it's simple.
Another point is syscall package. I have no time to explain this, sorry, vut you understand what I mean.
The third point is community. Google "golang coc". If you do not want to google, i'll try to explain: they wanted to stop accepting pull requests from those who argues a lot. Even if those pull requests are more useful than Pike's.
>And to my knowledge java isn't fully opensource. There is the openjdk but that requires java to compile before you can use it.
OpenJDK does not require Java to compile, lol. That would be as autistic as go (compiler) 1.4.

>>

 No.11473

I'm just going to say that Go, Java, C++, Python, Ruby, et al. are all members of the Algol family of languages.

Examples of languages not in this family include APL, Forth, Lisp, and early Fortran.

>>

 No.11475

File: 1446667136050.jpg (8.33 KB, 250x250, 1431712235783.jpg) ImgOps Exif iqdb

>>11473
This superficial, meaningless, memetic, discussion-killing "ALGOL family" categorization needs to stop. It has been a favourite hot button for argumentative fuarrrks on Usenet and the Internet to press for decades, and it doesn't help anyone nor foster any productive discussion. It's even worse in the context of education: You have people saying "Oh, if you know Java, C is going to be easy to learn!", when they may as well be saying "Oh, if you know Smalltalk or Eiffel, you're going to have such an easy time learning Fortran!". They're both equally meaningless, and plant this conflation of syntax with semantics in growing programmers' brains, which is a tumour that they must then take it upon themselves, years later, to painfully remove. Where are Go's concurrency semantics in C? Where are Python's dynamic typing or Java's Common Lisp Object System/Smalltalk-style late binding in C++? Ruby is more like Scheme mixed with Smalltalk than anything ALGOL-ish.

You're doing the entire world of programming a disservice by implying that such a loosely-defined "family" constitutes some oppressive paradigm that needs to be broken out of, especially when a considerable portion of the modern world (Haskell, Clojure, Scala, ...) already lives outside of it even by the loosest, weaseliest definitions of "ALGOL-like". Even if the aforementioned languages aren't in somebody's day-to-day-repertoire, more people are more aware every day that they exist.

So, please, fuarrrking stop polluting everyone's mind space by pretending that just being contrarian constitutes insight. Yes, I'm mad.

>>

 No.11483

>>11445
this has nothing to do with Go. he just needed a language to talk soykaf about that wasn't Haskell.

>>

 No.11485

>>11445
>Mind you, the language is objectively poorly designed.
poor·ly  (poor′lē)
adv.
In a poor manner. See Usage Note at poor.
poor (poor)
adj. poor·er, poor·est
2. Deficient or lacking in a specified resource or quality: an area poor in timber and coal; a diet poor in calcium.
3. Not adequate in quality or quantity; inferior: a poor performance; poor wages.

objectively poorly is an oxymoron, literally by definition.

>The error handling

Because exception handling is so delightfully elegant, right.
>the lack of generics
This is a matter of taste and imagination, and can't possibly be an objective judgement.
>the ridiculous package manager
At least the go package manager knows what it is. Cabal is schizophrenic.
>the absurd type system
I'm assuming absurd here means "not algebraic".
>the range thing
It's a lot more regular than other ridiculously decorated loops. (I'm looking at you, Python.)
>It’s almost exactly the opposite of Haskell.
Nah, the opposite of Haskell would be something purely object-oriented.

>>

 No.11487

I just started programming in Go. Coming from C and java, I like it so far and it was really easy to jump into.

Im not sure if I am going to go deep into it(I was originally planning on learning python, not sure about that either) but Im thinking about getting the Go programming language book coming out in a couple days. Anyway thanks for the thread it was a good resource to inform me about the pros and cons of go.

>>

 No.11492

>>11475
I disagree with you.

Your C and Java comparison is a good example. They have a similar syntax, are both very weak languages, have similar scoping conventions from what I know, and share many other semantic qualities, like expressions and statements being different just as functions and operators are different, for no real reason.
C requires some manual memory management and is filled with undefined behavior. Java has OOP and runs on a VM. They have other differences, but they are still much more similar to each other and other members of the Algol family then they are to languages outside of that family.

>"Oh, if you know Smalltalk or Eiffel, you're going to have such an easy time learning Fortran!"

Fortran is not a member of the Algol family. I don't know much of anything about Eiffel.

Please don't compare a language like Ruby to anything in the Lisp family. It's clearly not true and gets old. Ruby isn't even homoiconic.

You should be able to realize that the Algol family is characterized by complicated syntax describing complicated semantics, followed by scope delimiters, be they {}, begin end, or Python's whitespace, and a general lack of power in comparison to other languages.

If you want more proof, know that C is derived from B, which was derived from BCPL, which was derived from CPL, which was derived from Algol 60. C is just a more tedious and less powerful derivative of Algol derivatives.
C++ is a derivative of C and heavily influenced Java and other Algol clones, like PHP.
I'll let you discern the similarities with the other Algol lookalikes, such as Ruby, Python, and Go.

>>

 No.11500

>>11492
>Fortran is not a member of the Algol family.
Neither is Smalltalk. I'll give you a hint: They're wildly different. So are C and Java. Sure, on the surface, some operations are vaguely the same, but you can't solve anything of scale in either with only working knowledge of the other. There are no unboxed values in Java; everything is behind a level of indirection. Primitives may not exist outside objects. The only difference, semantically, from Smalltalk, is the fact that primitives even exist. Yes, it's superficially similar to C, but you'd have a better time teaching somebody Smalltalk and then showing them Java than teaching somebody C then showing them Java.

>Please don't compare a language like Ruby to anything in the Lisp family. It's clearly not true and gets old. Ruby isn't even homoiconic.

Don't get upset that your sacred cow is getting whipped. I didn't even say it took any of Scheme or Smalltalk's *good* qualities, like homoiconicity. As a matter of fact, the quote that comes to mind is: "Ruby is Scheme mated to Smalltalk such that both failed to exert a phenotype." --anonymous

>You should be able to realize that the Algol family is characterized by complicated syntax describing complicated semantics, followed by scope delimiters, be they {}, begin end, or Python's whitespace, and a general lack of power in comparison to other languages.

If you think complex syntax is a trademark of the "ALGOL family" you're delusional.
http://xahlee.info/UnixResource_dir/writ/lisp_problems.html
A lack of power also comes to mind with anaemic parallelism and concurrency in non-purpose-built Lisps, or even when it is full-featured, it's a ridiculously intricate afterthought:
http://xahlee.info/comp/Guy_Steele_parallel_computing.html
For the record, Scheme's main feature over earlier Lisps is ALGOL-style lexical scoping, instead of older Lisp's historical accident of a dynamic scoping system. I bet you'd be reluctant to call Scheme a member of the ALGOL family, though, because, while it's about as sensible as your baseless, meaning-destroying categorizations, it puts something you appreciate into a group you have reserved for "things I don't like".

>If you want more proof, know that C is derived from B, which was derived from BCPL, which was derived from CPL, which was derived from Algol 60. C is just a more tedious and less powerful derivative of Algol derivatives.

I'm not going to address your opinion on C, but I never denied that C has a long, twisty family lineage to ALGOL. It's a leap to say that block scoping makes anything ALGOL-like though.

Taxonomy, among other bookkeeping, truly is the lowest form of science, and it can not only be mindless, but *harmful* when it attempts to synthesize meaning out of thin air. Using it to express an opinion is an equally heinous crime. Stop using ill-defined categories to pass judgement.

>>

 No.11512

>>11500
I don't know enough about Smalltalk to comment. I failed to mention a particularly telling characteristic of the Algol family, which is both the semicolon and all of the reserved keywords you find in these languages. Now, some languages have keywords, like Fortran, but older Fortran is not structured like Algol, among other differences.

Now, you may say, "But Lisp has special forms and that's the same thing." but I would disagree. Common Lisp has a module system that allows you to assign any meaning to any symbol and you can easily override even the dreaded parenthesis syntax by manipulating the readtable, among other things.

Forth is a language with almost no syntax. Words are separated by spaces and some words, like : ;, if then, and for next, have to be matched up, if you don't change their definitions before using them.

APL has primitives, but you also need a special input method just to use it and so I wouldn't consider them reserved keywords. There are probably APL systems that allow you to redefine them if you really wanted to.

Meanwhile, Go has implicit semicolons and boasts about a compiler hack from, none other than, BCPL.

https://golang.org/doc/faq
>Go uses brace brackets for statement grouping, a syntax familiar to programmers who have worked with any language in the C family. Semicolons, however, are for parsers, not for people, and we wanted to eliminate them as much as possible. To achieve this goal, Go borrows a trick from BCPL: the semicolons that separate statements are in the formal grammar but are injected automatically, without lookahead, by the lexer at the end of any line that could be the end of a statement. This works very well in practice but has the effect that it forces a brace style. For instance, the opening brace of a function cannot appear on a line by itself.

>Don't get upset that your sacred cow is getting whipped. I didn't even say it took any of Scheme or Smalltalk's *good* qualities, like homoiconicity. As a matter of fact, the quote that comes to mind is: "Ruby is Scheme mated to Smalltalk such that both failed to exert a phenotype." --anonymous

That's a funny quote.

>If you think complex syntax is a trademark of the "ALGOL family" you're delusional.

That was poor phrasing on my part. I was primarily talking about all of the reserved keywords and other syntax one must learn. It's rather strange to me.

>A lack of power also comes to mind with anaemic parallelism and concurrency in non-purpose-built Lisps, or even when it is full-featured, it's a ridiculously intricate afterthought:

That's a fair point. The problem is with the lack of standardization. You just have to chain yourself to an implementation or use a library that gives a common interface over many implementations.

>For the record, Scheme's main feature over earlier Lisps is ALGOL-style lexical scoping, instead of older Lisp's historical accident of a dynamic scoping system. I bet you'd be reluctant to call Scheme a member of the ALGOL family, though, because, while it's about as sensible as your baseless, meaning-destroying categorizations, it puts something you appreciate into a group you have reserved for "things I don't like".

I wouldn't consider Scheme a member of the Algol family just because of that.
I really am sorry for being rude earlier. Just now that I find it strange to look at a language like Go, where you can't mess with the compiler on a whim (Unless I'm wrong?), and I call that less powerful. It's alien to me to look at a language where you have to be so redundant and verbose.
I'm not trying to be a zealot. I just firmly believe that most of these languages out nowadays are just superficially different flavors of Algol and I feel I've made the case for that. I didn't insult Go in >>11473, I just stated what I felt was a reasonable assertion.

>>

 No.11513

>>11500
>>11512
>I'm not going to address your opinion on C, but I never denied that C has a long, twisty family lineage to ALGOL. It's a leap to say that block scoping makes anything ALGOL-like though.
I have now pointed out many other similarities.

>Taxonomy, among other bookkeeping, truly is the lowest form of science, and it can not only be mindless, but *harmful* when it attempts to synthesize meaning out of thin air. Using it to express an opinion is an equally heinous crime. Stop using ill-defined categories to pass judgement.

I don't feel that I've done anything wrong and I continue with my belief that these languages are simply versions of Algol.

Once again, I'm not trying to be rude or ruin this thread or anything like that. I would like to know why you like Go, if you'll tell me.

>>

 No.11520

>Meanwhile, Go has implicit semicolons and boasts about a compiler hack from, none other than, BCPL.
So does Haskell, albeit merged with Python's off-side rule, such that specifically aligned whitespace inserts semicolons and braces in constructs like "do", making both
take m ys = case (m,ys) of
(0,_) -> []
(_,[]) -> []
(n,x:xs) -> x : take (n-1) xs

and
take m ys = case (m,ys) of {
(0,_) -> [];
(_,[]) -> [];
(n,x:xs) -> x : take (n-1) xs;
}

equally acceptable; in fact the former renders to the latter. Haskell isn't exactly ALGOL-family.

Also, I wouldn't say Go *brags* about borrowing the trick from BCPL, but rather gives credit where credit is due. There, you could indeed deduce a specific link, but it's not like the feature is a specific mark of the ALGOL family, as seen in the Haskell example.

>I was primarily talking about all of the reserved keywords and other syntax one must learn. It's rather strange to me.


Inflexibility to one person is consistency to somebody else, and consistency is key in large-scale development. Imagine the chaos that would ensue if choice of keywords were up to a *style guide* in a large project. Go is built for development in the large. However, unlike Java, Go was not built explicitly for people dumber than the creators, otherwise Rob et al. would still be using C. In fact, they wrote a language *they* wanted to use.

>Just now that I find it strange to look at a language like Go, where you can't mess with the compiler on a whim (Unless I'm wrong?), and I call that less powerful. It's alien to me to look at a language where you have to be so redundant and verbose.


See above, although the compiler's mechanics are mostly found in the standard library. For instance, gofmt (pretty prints to the vetted format) is a relatively trivial application that uses the standard library's built-in resources for manipulating the language's AST. It parses, but does not lex, then spits out the AST pretty-printed. This isn't accessible at run time on the code itself, since it's compiled, sure, but the language is far easier to manipulate itself with, than, say C. At the cost of being even less syntactically flexible than C, the grammar *is* much simpler, and as a result, it's remarkably easy to write utilities of this style.

>I would like to know why you like Go, if you'll tell me.

You'll find a lot of reasons in what I just typed. There are probably others.
The most important, I suppose, is that I actually enjoy writing code in it, and going back to Python, Ruby, Java, C++, or GNU/POSIX/BSD C just feels depressing. The only languages that I *enjoy* as much as Go are probably Plan 9 C and R5RS Scheme.

>>

 No.11523

>>11520
Any resources for learning Plan 9 C? I keep hearing that it is the only sane way to write in C.

>>

 No.11524


>>

 No.11527

>>11520
>Haskell isn't exactly ALGOL-family.
I don't know enough about Haskell to determine if I would call it a member of the Algol family or not.
We don't exactly agree on what constitutes the Algol family or not.
What differentiates Haskell from other languages, asides from its using pure functions where other languages have procedures?

>Inflexibility to one person is consistency to somebody else, and consistency is key in large-scale development. Imagine the chaos that would ensue if choice of keywords were up to a *style guide* in a large project.

The languages I use don't have keywords, so I can't relate to your example. Heavily modifiable languages seem to do just fine with their compiler hacks and relatively massive changes to the language.

>Go is built for development in the large. However, unlike Java, Go was not built explicitly for people dumber than the creators, otherwise Rob et al. would still be using C. In fact, they wrote a language *they* wanted to use.

That sounds like a fair enough justification. Of course, the people designing the language get to decide what they want, while modifiable languages let everyone decide what they want. Go gets a lot of flack for not including generics, apparently. Imagine being able to add them, or anything else, yourself.

>See above, although the compiler's mechanics are mostly found in the standard library. For instance, gofmt (pretty prints to the vetted format) is a relatively trivial application that uses the standard library's built-in resources for manipulating the language's AST. It parses, but does not lex, then spits out the AST pretty-printed. This isn't accessible at run time on the code itself, since it's compiled, sure, but the language is far easier to manipulate itself with, than, say C. At the cost of being even less syntactically flexible than C, the grammar *is* much simpler, and as a result, it's remarkably easy to write utilities of this style.

Being better than C doesn't really strike me as impressive. Even Forth has words that do things like print the source for a word dynamically and usually printy-printed. It's called SEE.

>You'll find a lot of reasons in what I just typed. There are probably others.

>The most important, I suppose, is that I actually enjoy writing code in it, and going back to Python, Ruby, Java, C++, or GNU/POSIX/BSD C just feels depressing. The only languages that I *enjoy* as much as Go are probably Plan 9 C and R5RS Scheme.
That's fair enough. I'm not telling you your preferences are wrong or anything.

>>

 No.11528

>>11527
>What differentiates Haskell from other languages, asides from its using pure functions where other languages have procedures?

Purely-functional, and models state and side effects through monads. Has plenty of methods for creating operators with the associativity and precedence you want. Some call it Lisp's missing M-expr engine.

>The languages I use don't have keywords, so I can't relate to your example.

What languages do you use?

>Of course, the people designing the language get to decide what they want, while modifiable languages let everyone decide what they want.

Sure. It just so happens that what I want coincides with what some ex-Bell Labs researchers on display at Google wanted. And what plenty of other people want, judging by usage.

>Go gets a lot of flack for not including generics, apparently. Imagine being able to add them, or anything else, yourself.

There would be little point. They would be as out-of-place an abstraction, as, say, a system to create static, restricted objects (C++ style) in Common Lisp, where the dynamicity of CLOS is idiomatic.

>Being better than C doesn't really strike me as impressive.

I think you missed the idea here. The point is that the tools are there, and you can do manipulation of source at any stage of compilation. The pretty-printer is just one of uncountable possibilities. Especially since the self-hosting release, it becomes incredibly easy to mess with the compiler, especially given the lightning-fast compiles that people love Go for.

>>

 No.11530

>>11528
>Purely-functional, and models state and side effects through monads. Has plenty of methods for creating operators with the associativity and precedence you want. Some call it Lisp's missing M-expr engine.
I really wish either I knew enough about Haskell or we had a third party to give an opinion on it.

>What languages do you use?

Forth and Lisp are two languages I use.

>Sure. It just so happens that what I want coincides with what some ex-Bell Labs researchers on display at Google wanted. And what plenty of other people want, judging by usage.

What about when you want something and they don't?

>There would be little point. They would be as out-of-place an abstraction, as, say, a system to create static, restricted objects (C++ style) in Common Lisp, where the dynamicity of CLOS is idiomatic.

I've seen plenty of "pointless" things that can be done in Lisp, but that doesn't mean I wouldn't want to be able to do them.
CLOS was originally designed as macros on top of the base system.

>I think you missed the idea here. The point is that the tools are there, and you can do manipulation of source at any stage of compilation. The pretty-printer is just one of uncountable possibilities. Especially since the self-hosting release, it becomes incredibly easy to mess with the compiler, especially given the lightning-fast compiles that people love Go for.

Out of curiosity, how large is the Go compiler, in terms of LoC?

>>

 No.11545

>>11530
>I really wish either I knew enough about Haskell or we had a third party to give an opinion on it.
Just one important thing: Operators are just functions with an optional special syntax. The names are semantic to how they're parsed. All alphanum makes it prefix; symbols make it infix. You can make binary prefix functions infix by doing op1 `func` op2, and infix into prefix by doing (+) 1 2.

>Forth and Lisp are two languages I use.

Neat, we match up on Lisp.

>What about when you want something and they don't?

I don't know. I don't run into this problem, really. Call it stockholm syndrome, but I'm happy to be a little verbose once if the compiler can, for the most part, blaze through it for the large number of times that code is going to get built.

>Out of curiosity, how large is the Go compiler, in terms of LoC?

Can't remember off the top of my head, but here's a mirror of their repository: https://github.com/golang/go

>>

 No.11546

>>11530
As an addendum to >>11545
https://github.com/golang/go/tree/master/src/cmd/compile

Here is the relevant subdirectory.

>>

 No.11573

I needs easy GUI creation features. Specifically a visual GUI manager.

>>

 No.11574

>>11573
>Specifically a visual GUI manager.
not sure this exists. there are binding libraries for all the usual frameworks, nothing polished though.

>>

 No.11693

There's no reason to be using Golang when Nim can do everything it does but better (except arguably coroutines).

>>

 No.11696

>>11693
Nim has nowhere near the level of corporate backing that Go does, which (like it or not) is a large factor in deciding how successful a language will be. Go also has a better standard library than Nim. However I agree with your point about Nim being more powerful.

>>

 No.11720

>>11696
>how successful a language will be
What does this even mean?

>>

 No.11740

>>11720
s/successful/popular/

>>

 No.11866

It seems that golang does not suck at properly handling unicode, unlike... others.
https://www.azabani.com/pages/gbu/

>>

 No.11874

>>11866
>unlike... others.
You mean Perl. Perl is still kicking ass in 2015 and nobody seems to have learned anything from it except to encourage readable code.

>>

 No.11893

>>10961
I don't understand why making programming languages easier is bad. IMO the more people who know how to program the better it is for our society. Even if most of them are crap programmers the total amount of quality programmers will go up.

Decreasing the value of programmers may be bad for programming wages but demanding more arcane languages like C++ is not the answer.

Its like fully automated production. It can lead to an imbalance between capitalists and the proletariat. But the solution isn't to ban fully automated production. Its to undo the system where everyone must work to live.

>>

 No.11894

>>11893
>I don't understand why making programming languages easier is bad.
Nobody is saying that. It's bad to prioritize easiness over other values in order to exploit programmers. Why do you think so many people hate Java?
>IMO the more people who know how to program the better it is for our society.
Better for society can mean many things and does not necessarily mean better for the people belonging to the society.
>Even if most of them are crap programmers the total amount of quality programmers will go up.
If the supply of quality programmers goes up, the demand goes down, and wages drop. Unless you're a large software company, that's bad.
>Its like fully automated production. It can lead to an imbalance between capitalists and the proletariat. But the solution isn't to ban fully automated production. Its to undo the system where everyone must work to live.
Unions would be a nice start.

>>

 No.11900

>>11874
uh.. no I meant everything mentioned in the presentation except perl and golang. Because they all don't seem to implement a significant amount of the (admittedly huge amount) of standards related to unicode, wtf.

I actually had messed around with unicode in JS an thought everything was fine but that doesn't seem to be the case. I did not know unicode from utf-8 before so yeah

I like that this seems to have been considered from the very beginning in golang so they dont have to worry about legacy shit

>>

 No.11918

>>11894
> If the supply of quality programmers goes up, the demand goes down, and wages drop.

The surplus of programmers isn't the problem. And I still maintain it is good. Wages dropping is the problem. Unions as you suggest, is a solution but I think wages is the root cause. More libre software and libraries puts the means of production back into the hands of proles and for more libre software we need more programmers.

>>

 No.11928

>>11071
this is a known hoax

>>

 No.11930

>>11928

I thought it was obvious satire.

>>

 No.11931

>>11918
Not the guy you're responding to, but

>The surplus of programmers isn't the problem. And I still maintain it is good. Wages dropping is the problem

If you admit that wages dropping is the problem, then surely you shouldn't be in favor of something (a surplus of programmers) that directly causes it?

>More libre software and libraries puts the means of production back into the hands of proles

See, that would only be effective if the vast majority of programmers were or intended to be freelance entrepreneurs. For employed programmers, though, making libre software can be a gratifying exercise, but won't put food on the table.

>>

 No.11936

>>11918
>More libre software and libraries puts the means of production back into the hands of proles and for more libre software we need more programmers.
That's only true for copyleft licensed software. Permissive licenses like the MIT just provide corporations free labor.

>>

 No.11941

>>11931
Let sp = surplus of programmers
Let lw = lower wages for programmers
We agree that sp -> lw and lw is bad.
Your conclusion is that sp is also bad. I say sp is good and the association (sp -> lw) is bad. So instead of fighting to make sp not true we should fight to make (sp -> lw) not true.

>>11936
Interesting please elaborate.

>>

 No.11942

>>11941
>The modern trend in FOSS is away from the GPL and towards MIT/BSD. That's no surprise, because GPL is awkward for corporations. Red Hat endorses the MIT/BSD model. And as corporations encourage the development of these new liberal licenses, we find that Stallman is being exorcised as an aging hippy, not 'with it', an embarrassment, uncouth, and so on. In plain terms, Stallman has outlived his usefulness as a stooge. There are better and brighter ways to encourage FOSS than the aging GPL. Goodbye Mr Stallman.
http://www.shenlanguage.org/lambdassociates/htdocs/blog/the_problems_of_open_source.htm

I don't agree with everything in here, but you get the point.

>>

 No.11947

>>11941
>we should fight to make (sp -> lw) not true

How? Let's say you find a way to fix wages at an artificially higher level. What would happen is that companies would hire less. This would be good for the remaining employees, as they would not only have higher salaries but would also be encouraged to explore unconventional programming languages and concepts to make up for the lower number of people working on a project. However, when you add lower hiring to a surplus of programmers, you get a lot of joblessness. Sure, some of these programmers could become freelance entrepreneurs, but it would still be a net loss in terms of job security for a large number of people.

>>

 No.11948

>>11941
This is a simple example of supply and demand. Supply goes up, demand goes down. Surplus always leads to lower demand.

>>

 No.11952

>>11948
No soykaf that's the current case. The idea is to try to create a scenario where people are not products and not subject to supply and demand.

>>11947
I'm not suggesting wage fixing I'm just saying we need to think out of the box and have A solution. I think the solution is to replace wages with something else. What that is I don't know.

More skilled and educated people _should_ lead to a more prosperous society for all but instead it impoverishes many and only strengthens few. I don't want a society that works that way.

nb cause we are real off topic now and should probably start a new thread.

>>

 No.11958

>>11952
>I think the solution is to replace wages with something else.

Fair enough. I suppose you could make something like, say, a programmers' guild. Not that that wouldn't have a few problems of its own, of course.

>>

 No.11959

>>11952
>No soykaf that's the current case. The idea is to try to create a scenario where people are not products and not subject to supply and demand.
It wouldn't be a surplus unless there were more than needed. That is always the case.



Delete Post [ ]
[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]