Which language has the brightest future in replacement of C between D, Go and Rust? And Why?# Programming - 葵花宝典
p*e
1 楼
我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
谢谢
谢谢
z*7
2 楼
Which language has the brightest future in replacement of C between D, Go
and Rust? And Why?
In spite of my status and obvious bias as co-creator of D, I'll do my best
to answer candidly; I follow Go and Rust, and I also definitely know where D
's dirty laundry is. I'd encourage people with similar positions in the Rust
and Go communities to share their honest opinion as well. So here goes.
First off, C++ needs to be somewhere in the question. Whether it's to be
replaced alongside C, or be one of the candidates that's supposed to replace
C, the C++ language is a key part of the equation. It's the closest
language to C and the obvious step up from it. Given C++'s age, I'll assume
in the following that the question also puts C++ alongside with C as a
target for replacement.
Each language has a number of fundamental advantages (I call them "10x
advantages" because they are qualitatively in a different league compared to
at least certain baselines) and a number of challenges. The future of these
languages, and their success in supplanting C, depends on how they can use
their 10x advantages strategically, and how they overcome their challenges.
So let me dispense with D first
Obviously this is my house's tour so I know where to walk you all to
appropriately show/hide the clean and dirty corners. I'll also have probably
more to say about D than the two others for the simple reasons I know more
about D than the two others. Speaking with brutal honesty, D's main
challenges are:
Poor adoption after many nominal years of existence. Insiders to the D
community could qualify this statement (D in its current form is relatively
new, adoption does grow, etc). Yet the perception remains, and adoption is
driven by perception and becomes fact. So managers and engineers are nervous
about adopting a language that's been around unsuccessfully for so long.
Furthermore, time works against D unless/until a major uptick in adoption
becomes obvious.
Weak story about D's relationship to garbage collection. GC is a great
invention, but the decision to use it for D has instantly alienated a core
market - existing C and C++ programmers. For those, the party line has
historically been "Don't want GC? No problem! You can use D with RAII or
manual management style as well!" Though true, that's next to useless
because there's little support in the standard library for alternative
memory management styles, which means the putative user would need to start
with the language stripped down to the studs and create all the core
infrastructure. Also, for those who are okay with using a GC, the quality of
its implementation is lackluster. Overall it could be said that D has the
downsides of GC but doesn't enjoy its benefits.
A historical lack of vision. Absent corporate support, D has been community-
driven, where engineering acumen is easier to find than long-term vision,
charisma, and leadership. For a good while, the stridency of D's attempts at
promotion and PR has had negative value. The first vision document http://wiki.dlang.org/Vision/2015H1 is dated January 1, 2015, and the next iteration (Vision/2015H2 - D Wiki) has been four months late in a six-months cycle, which is at best ironic.
There would be, of course, other issues but they either derive from the
above or have a much smaller impact.
D's 10x advantages are, I think, the following (when I say "10x" in the
following I mean it colloquially a la "one order of magnitude"):
10x faster to compile than C++ for comparable produced code. This gap is
essentially impossible to bridge for C++ and prohibitively difficult for any
other language. (Go compiles a tad faster than D, but produces slower code.
) The experience of using a system language that builds this fast code this
fast is transformative and far-reaching. Combined with D's abstraction power
, it essentially makes D a good choice for writing highly optimized code for
the simple reason that experimentation has a low cost.
10x faster than scripting languages for comparable convenience. A good use
of D is as a convenient scripting language for a variety of casual tasks.
The build/run cycle is just as quick, and the gain in speed is enormous.
Also, there's no "hitting the wall" effect - if a script grows large, D has
always more power and modular mechanisms to offer. Of course, this must be
taken with a grain of salt because e.g. Python has much more libraries
available. But the 10x gap is fundamental: systems languages would have
difficulty getting to D's level of conviviality, whereas scripting languages
would have difficulty closing the speed gap.
10x easier to interface with C and C++ than any other language. D uses the
same memory layout as C and C++; all it does is build structure on top of it
, but the lower layers are readily accessible at no cost. The entire C
standard library is readily accessible at no syntactic or speed cost, there
is work to allow the same for the C++ standard library, and many C
libraries are easy to interface with https://github.com/D-Programming....
It could be claimed that literally no other language can reach that level of
integration.
10x better than any other system language at generic and generative
programming. D's static introspection, compile-time evaluation, and mixin-
driven code generation combine to a powerful cocktail that is very difficult
to mix right in other languages, be they new or extant; at this game, Go is
so out of depth it doesn't even get the point; C++17 is hopelessly lost in
the woods; and Rust is just trying to dabble.
On to Go
I should reinforce here that this is solely my opinion, worth what you pay
for it. Go's challenges are the following:
Fundamental slowdown due to indirect calls and garbage collection. Virtually
no meaningful Go can be written without resorting to indirect function
calls and garbage collection, which are central to its core features. These
are major impediments to achieving in-core performance. The response of the
Go team has been tactical, e.g. work on a better garbage collector. However,
it's unlikely that the challenge of replacing C can be won tactically.
Politics. Go's party line has been disproportionately strong and rigid on a
number of issues, small and large. Among the larger issues, the approach on
generics has been heavy-handed and demeaning enough to make generics the N
word of Go; the whole topic has become enough of a stigma to discourage any
attempts at meaningful dialog. I think politicizing of technical matters is
an extremely damaging pattern in the long run, and I hope Go finds a way to
repair this.
Simple-cum-simplistic. Go is famously simple - there are anecdotes of people
picking it up quickly. However, that becomes problematic as time goes by;
Go code is hopelessly pedestrian - Go coders find themselves writing again
and again the same things from an ant's vantage point because Go cannot
abstract even the simplest notions or algorithms. Domains that are not
already served by easy to glue libraries are difficult to get into. There is
backlash from coders who have used Go for one project and wouldn't want to
ever use it again. It would be great if Go made life better for repeat
customers.
Go's 10x advantages are in my perception the following:
10x better strategy. After a brief period in which Go claimed to be a
systems programming language, it has fully committed to the niche of
networking services. This has been a brilliant marketing move, which
capitalized on the strengths of the Go team (some of the best engineers in
the world at networking services). That market is hot, and Go was a fresh
breath of air in a world dominated by Java EE bureaucracy and slow scripting
languages. Now Go is a major player in that area, and it would be difficult
to displace it.
10x engineering. Go has a solid engineering team behind it, and that's a
major influencer of the quality of the language and in particular the
networking library and the tooling. Until now, good engineering has
compensated very well for the lack of power in the language.
10x branding. Many of us are ready to admit that a main motivator of Go is
its connection to Google. That gives it a clout of professionalism, quality,
and stability. Of course, brand is not everything, but what it means is all
Go has to do is be a decent language; it doesn't have to be a fantastic
language. The brand works out the rest.
Last but not least, Rust
Let me again remind that this is only my opinion. I think Rust is facing
some interesting challenges:
A disharmonic personality. Reading any amount of Rust code evokes the joke "
friends don't let friends skip leg day" and the comic imagery https://www.
google.com/search?q=...) of men with hulky torsos resting on skinny legs.
Rust puts safe, precise memory management front and center of everything.
Unfortunately, that's seldom the problem domain, which means a large
fraction of the thinking and coding are dedicated to essentially a clerical
job (which GC languages actually automate out of sight). Safe, deterministic
memory reclamation is a hard problem, but is not the only problem or even
the most important problem in a program. Therefore Rust ends up expending a
disproportionately large language design real estate on this one matter. It
will be interesting to see how Rust starts bulking up other aspects of the
language; the only solution is to grow the language, but then the question
remains whether abstraction can help the pesky necessity to deal with
resources at all levels.
Foreign syntax. Rust's syntax is different, and there's no apparent
advantage to the difference. This is irritating for folks coming from Algol-
style languages, who need to deal with a gratuitously different syntax in
addition to getting the resource bookkeeping right.
Rust's 10x advantages are:
10x better theorists. Of the three, Rust is the only language with world-
class PL theorists on roster. This can be seen in the precise definition of
the language and the depth of its technical approach.
10x better safety than other systems programming languages. Of course that
had to be here, we just discussed the cost of that.
10x better PR. There has been a long period pre-1.0 when Rust was a
community darling and could do no wrong: whatever problem there was, either
Rust had a solution to it, or will have had by 1.0. The realities of 1.0
ended that honeymoon and marked (by my measurements and estimates) a stark
decrease in general interest, but these effects have a way to linger. Plus,
after all, Rust is a decent language with real things going for it, and it's
well positioned to convert this lingering hype into solid marketing.
In brief
Whether any of these languages is well positioned to either progressively
replace C, C++, or both in existing codebases; and whether any of these
languages become preferred choices for projects that today would choose C or
C++ by default---it all depends on the ability of these languages to play
into their respective strengths and find creative solutions to their
respective challenges.
and Rust? And Why?
In spite of my status and obvious bias as co-creator of D, I'll do my best
to answer candidly; I follow Go and Rust, and I also definitely know where D
's dirty laundry is. I'd encourage people with similar positions in the Rust
and Go communities to share their honest opinion as well. So here goes.
First off, C++ needs to be somewhere in the question. Whether it's to be
replaced alongside C, or be one of the candidates that's supposed to replace
C, the C++ language is a key part of the equation. It's the closest
language to C and the obvious step up from it. Given C++'s age, I'll assume
in the following that the question also puts C++ alongside with C as a
target for replacement.
Each language has a number of fundamental advantages (I call them "10x
advantages" because they are qualitatively in a different league compared to
at least certain baselines) and a number of challenges. The future of these
languages, and their success in supplanting C, depends on how they can use
their 10x advantages strategically, and how they overcome their challenges.
So let me dispense with D first
Obviously this is my house's tour so I know where to walk you all to
appropriately show/hide the clean and dirty corners. I'll also have probably
more to say about D than the two others for the simple reasons I know more
about D than the two others. Speaking with brutal honesty, D's main
challenges are:
Poor adoption after many nominal years of existence. Insiders to the D
community could qualify this statement (D in its current form is relatively
new, adoption does grow, etc). Yet the perception remains, and adoption is
driven by perception and becomes fact. So managers and engineers are nervous
about adopting a language that's been around unsuccessfully for so long.
Furthermore, time works against D unless/until a major uptick in adoption
becomes obvious.
Weak story about D's relationship to garbage collection. GC is a great
invention, but the decision to use it for D has instantly alienated a core
market - existing C and C++ programmers. For those, the party line has
historically been "Don't want GC? No problem! You can use D with RAII or
manual management style as well!" Though true, that's next to useless
because there's little support in the standard library for alternative
memory management styles, which means the putative user would need to start
with the language stripped down to the studs and create all the core
infrastructure. Also, for those who are okay with using a GC, the quality of
its implementation is lackluster. Overall it could be said that D has the
downsides of GC but doesn't enjoy its benefits.
A historical lack of vision. Absent corporate support, D has been community-
driven, where engineering acumen is easier to find than long-term vision,
charisma, and leadership. For a good while, the stridency of D's attempts at
promotion and PR has had negative value. The first vision document http://wiki.dlang.org/Vision/2015H1 is dated January 1, 2015, and the next iteration (Vision/2015H2 - D Wiki) has been four months late in a six-months cycle, which is at best ironic.
There would be, of course, other issues but they either derive from the
above or have a much smaller impact.
D's 10x advantages are, I think, the following (when I say "10x" in the
following I mean it colloquially a la "one order of magnitude"):
10x faster to compile than C++ for comparable produced code. This gap is
essentially impossible to bridge for C++ and prohibitively difficult for any
other language. (Go compiles a tad faster than D, but produces slower code.
) The experience of using a system language that builds this fast code this
fast is transformative and far-reaching. Combined with D's abstraction power
, it essentially makes D a good choice for writing highly optimized code for
the simple reason that experimentation has a low cost.
10x faster than scripting languages for comparable convenience. A good use
of D is as a convenient scripting language for a variety of casual tasks.
The build/run cycle is just as quick, and the gain in speed is enormous.
Also, there's no "hitting the wall" effect - if a script grows large, D has
always more power and modular mechanisms to offer. Of course, this must be
taken with a grain of salt because e.g. Python has much more libraries
available. But the 10x gap is fundamental: systems languages would have
difficulty getting to D's level of conviviality, whereas scripting languages
would have difficulty closing the speed gap.
10x easier to interface with C and C++ than any other language. D uses the
same memory layout as C and C++; all it does is build structure on top of it
, but the lower layers are readily accessible at no cost. The entire C
standard library is readily accessible at no syntactic or speed cost, there
is work to allow the same for the C++ standard library, and many C
libraries are easy to interface with https://github.com/D-Programming....
It could be claimed that literally no other language can reach that level of
integration.
10x better than any other system language at generic and generative
programming. D's static introspection, compile-time evaluation, and mixin-
driven code generation combine to a powerful cocktail that is very difficult
to mix right in other languages, be they new or extant; at this game, Go is
so out of depth it doesn't even get the point; C++17 is hopelessly lost in
the woods; and Rust is just trying to dabble.
On to Go
I should reinforce here that this is solely my opinion, worth what you pay
for it. Go's challenges are the following:
Fundamental slowdown due to indirect calls and garbage collection. Virtually
no meaningful Go can be written without resorting to indirect function
calls and garbage collection, which are central to its core features. These
are major impediments to achieving in-core performance. The response of the
Go team has been tactical, e.g. work on a better garbage collector. However,
it's unlikely that the challenge of replacing C can be won tactically.
Politics. Go's party line has been disproportionately strong and rigid on a
number of issues, small and large. Among the larger issues, the approach on
generics has been heavy-handed and demeaning enough to make generics the N
word of Go; the whole topic has become enough of a stigma to discourage any
attempts at meaningful dialog. I think politicizing of technical matters is
an extremely damaging pattern in the long run, and I hope Go finds a way to
repair this.
Simple-cum-simplistic. Go is famously simple - there are anecdotes of people
picking it up quickly. However, that becomes problematic as time goes by;
Go code is hopelessly pedestrian - Go coders find themselves writing again
and again the same things from an ant's vantage point because Go cannot
abstract even the simplest notions or algorithms. Domains that are not
already served by easy to glue libraries are difficult to get into. There is
backlash from coders who have used Go for one project and wouldn't want to
ever use it again. It would be great if Go made life better for repeat
customers.
Go's 10x advantages are in my perception the following:
10x better strategy. After a brief period in which Go claimed to be a
systems programming language, it has fully committed to the niche of
networking services. This has been a brilliant marketing move, which
capitalized on the strengths of the Go team (some of the best engineers in
the world at networking services). That market is hot, and Go was a fresh
breath of air in a world dominated by Java EE bureaucracy and slow scripting
languages. Now Go is a major player in that area, and it would be difficult
to displace it.
10x engineering. Go has a solid engineering team behind it, and that's a
major influencer of the quality of the language and in particular the
networking library and the tooling. Until now, good engineering has
compensated very well for the lack of power in the language.
10x branding. Many of us are ready to admit that a main motivator of Go is
its connection to Google. That gives it a clout of professionalism, quality,
and stability. Of course, brand is not everything, but what it means is all
Go has to do is be a decent language; it doesn't have to be a fantastic
language. The brand works out the rest.
Last but not least, Rust
Let me again remind that this is only my opinion. I think Rust is facing
some interesting challenges:
A disharmonic personality. Reading any amount of Rust code evokes the joke "
friends don't let friends skip leg day" and the comic imagery https://www.
google.com/search?q=...) of men with hulky torsos resting on skinny legs.
Rust puts safe, precise memory management front and center of everything.
Unfortunately, that's seldom the problem domain, which means a large
fraction of the thinking and coding are dedicated to essentially a clerical
job (which GC languages actually automate out of sight). Safe, deterministic
memory reclamation is a hard problem, but is not the only problem or even
the most important problem in a program. Therefore Rust ends up expending a
disproportionately large language design real estate on this one matter. It
will be interesting to see how Rust starts bulking up other aspects of the
language; the only solution is to grow the language, but then the question
remains whether abstraction can help the pesky necessity to deal with
resources at all levels.
Foreign syntax. Rust's syntax is different, and there's no apparent
advantage to the difference. This is irritating for folks coming from Algol-
style languages, who need to deal with a gratuitously different syntax in
addition to getting the resource bookkeeping right.
Rust's 10x advantages are:
10x better theorists. Of the three, Rust is the only language with world-
class PL theorists on roster. This can be seen in the precise definition of
the language and the depth of its technical approach.
10x better safety than other systems programming languages. Of course that
had to be here, we just discussed the cost of that.
10x better PR. There has been a long period pre-1.0 when Rust was a
community darling and could do no wrong: whatever problem there was, either
Rust had a solution to it, or will have had by 1.0. The realities of 1.0
ended that honeymoon and marked (by my measurements and estimates) a stark
decrease in general interest, but these effects have a way to linger. Plus,
after all, Rust is a decent language with real things going for it, and it's
well positioned to convert this lingering hype into solid marketing.
In brief
Whether any of these languages is well positioned to either progressively
replace C, C++, or both in existing codebases; and whether any of these
languages become preferred choices for projects that today would choose C or
C++ by default---it all depends on the ability of these languages to play
into their respective strengths and find creative solutions to their
respective challenges.
N*w
3 楼
no go
【在 p***e 的大作中提到】
: 我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
: 谢谢
【在 p***e 的大作中提到】
: 我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
: 谢谢
g*t
4 楼
都不可能。这事半导体公司至少要占一半因素。做cpu的时候，c compiler,CPU
simulator很多都是一起写的。嵌入式上电后的步骤和watch dog, sleep mode等很多东
西的逻辑都是c描述的。这不是语言问题，改工作流程风险太大，代价太高。做一个芯
片动辄几十M投资，说吃饱撑了才去替换c
如果今后
都是Ann 芯片或者量子计算了，那说不定有可能。
simulator很多都是一起写的。嵌入式上电后的步骤和watch dog, sleep mode等很多东
西的逻辑都是c描述的。这不是语言问题，改工作流程风险太大，代价太高。做一个芯
片动辄几十M投资，说吃饱撑了才去替换c
如果今后
都是Ann 芯片或者量子计算了，那说不定有可能。
j*a
5 楼
可以
【在 p***e 的大作中提到】
: 我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
: 谢谢
【在 p***e 的大作中提到】
: 我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
: 谢谢
b*i
6 楼
该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
【在 g****t 的大作中提到】
: 都不可能。这事半导体公司至少要占一半因素。做cpu的时候，c compiler,CPU
: simulator很多都是一起写的。嵌入式上电后的步骤和watch dog, sleep mode等很多东
: 西的逻辑都是c描述的。这不是语言问题，改工作流程风险太大，代价太高。做一个芯
: 片动辄几十M投资，说吃饱撑了才去替换c
: 如果今后
: 都是Ann 芯片或者量子计算了，那说不定有可能。
【在 g****t 的大作中提到】
: 都不可能。这事半导体公司至少要占一半因素。做cpu的时候，c compiler,CPU
: simulator很多都是一起写的。嵌入式上电后的步骤和watch dog, sleep mode等很多东
: 西的逻辑都是c描述的。这不是语言问题，改工作流程风险太大，代价太高。做一个芯
: 片动辄几十M投资，说吃饱撑了才去替换c
: 如果今后
: 都是Ann 芯片或者量子计算了，那说不定有可能。
l*n
7 楼
需要DP->HDMI adapter,amazon上几块钱买一个,声音也能一起输出.
【在 p***e 的大作中提到】
: 我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
: 谢谢
【在 p***e 的大作中提到】
: 我的HD5570上没有HDMI， 这有这个DisplayPort, 能输出音频到电视上么？
: 谢谢
g*t
8 楼
Include有什么问题？
: 该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
【在 b***i 的大作中提到】
: 该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
: 该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
【在 b***i 的大作中提到】
: 该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
N*w
9 楼
电视以后会不会也加 DP？
不然又要多一种转接线
【在 l****n 的大作中提到】
: 需要DP->HDMI adapter,amazon上几块钱买一个,声音也能一起输出.
不然又要多一种转接线
【在 l****n 的大作中提到】
: 需要DP->HDMI adapter,amazon上几块钱买一个,声音也能一起输出.
n*l
10 楼
"It's (c++) the closest language to C and the obvious step up from it"
I think most kernel developers (including windows) and low level linux/unix
guys will have to disagree.
I think most kernel developers (including windows) and low level linux/unix
guys will have to disagree.
d*n
11 楼
买插头，别买线。
【在 N****w 的大作中提到】
: 电视以后会不会也加 DP？
: 不然又要多一种转接线
【在 N****w 的大作中提到】
: 电视以后会不会也加 DP？
: 不然又要多一种转接线
x*u
12 楼
C的include没问题，简单高速
C++语法太复杂，include导致编译难度指数级扩大
【在 g****t 的大作中提到】
: Include有什么问题？
:
:
: 该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
:
C++语法太复杂，include导致编译难度指数级扩大
【在 g****t 的大作中提到】
: Include有什么问题？
:
:
: 该用C就用C。不过C确实有很多问题。我觉得最大的问题是include
:
N*w
13 楼
转接头太多也烦
【在 d****n 的大作中提到】
: 买插头，别买线。
【在 d****n 的大作中提到】
: 买插头，别买线。
N*n
14 楼
include文件里那堆"#ifdef#ifndef"定制的宏是高级语言禁忌。C和C++无法
严格支持CODE REFACTORING就是因为这些模糊不清的宏定义。
【在 x****u 的大作中提到】
: C的include没问题，简单高速
: C++语法太复杂，include导致编译难度指数级扩大
d*n
15 楼
直接插在设备后面不取下来啊。
【在 N****w 的大作中提到】
: 转接头太多也烦
【在 N****w 的大作中提到】
: 转接头太多也烦
N*n
16 楼
这个要看操作系统，C崛起是因为UNIX。未来的计算平台是量子计算，量子计算
最流行的那个操作系统，其主打的程序语言就会最有前景。
【在 z***7 的大作中提到】
: Which language has the brightest future in replacement of C between D, Go
: and Rust? And Why?
: In spite of my status and obvious bias as co-creator of D, I'll do my best
: to answer candidly; I follow Go and Rust, and I also definitely know where D
: 's dirty laundry is. I'd encourage people with similar positions in the Rust
: and Go communities to share their honest opinion as well. So here goes.
: First off, C++ needs to be somewhere in the question. Whether it's to be
: replaced alongside C, or be one of the candidates that's supposed to replace
: C, the C++ language is a key part of the equation. It's the closest
: language to C and the obvious step up from it. Given C++'s age, I'll assume
n*l
18 楼
quantum computing is probably a fad, as the previous AI. anyone really
understand how this shit works besides someone in China?
【在 N********n 的大作中提到】
:
: 这个要看操作系统，C崛起是因为UNIX。未来的计算平台是量子计算，量子计算
: 最流行的那个操作系统，其主打的程序语言就会最有前景。
understand how this shit works besides someone in China?
【在 N********n 的大作中提到】
:
: 这个要看操作系统，C崛起是因为UNIX。未来的计算平台是量子计算，量子计算
: 最流行的那个操作系统，其主打的程序语言就会最有前景。
N*n
19 楼
Aliens sure do. That's why they are able to fly around in UFOs while
we are stuck on Earth, HOHO.
【在 n****l 的大作中提到】
: quantum computing is probably a fad, as the previous AI. anyone really
: understand how this shit works besides someone in China?
b*i
20 楼
是啊。如果某个变量没有宏干扰，能准确refactor吗？
【在 N********n 的大作中提到】
:
: Aliens sure do. That's why they are able to fly around in UFOs while
: we are stuck on Earth, HOHO.
【在 N********n 的大作中提到】
:
: Aliens sure do. That's why they are able to fly around in UFOs while
: we are stuck on Earth, HOHO.
N*n
21 楼
设计C的那个年代还没有REFACTOR的概念。宏定义这种玩意如果是学院派出身的会
敬而远之，C的设计者估计是游击队出身，路数比较野。
【在 b***i 的大作中提到】
: 是啊。如果某个变量没有宏干扰，能准确refactor吗？
g*t
22 楼
ken是贝尔实验室的电工。EE的。
2000年左右lucent完蛋，EE还有讨论过
【在 N********n 的大作中提到】
:
: 设计C的那个年代还没有REFACTOR的概念。宏定义这种玩意如果是学院派出身的会
: 敬而远之，C的设计者估计是游击队出身，路数比较野。
2000年左右lucent完蛋，EE还有讨论过
【在 N********n 的大作中提到】
:
: 设计C的那个年代还没有REFACTOR的概念。宏定义这种玩意如果是学院派出身的会
: 敬而远之，C的设计者估计是游击队出身，路数比较野。
s*o
23 楼
我对rust一直很感兴趣，可惜没时间去搞。但要说到replacing c and c++，这几个语
言大概都没啥希望
言大概都没啥希望
r*z
24 楼
C的创始人dmr当然是科班出身了："He graduated from Harvard University with
degrees in physics and applied mathematics", his PhD thesis on "Program
Structure and Computational Complexity" at Harvard.
这批CS先驱都有硬件的底子，研究风格比较实际，设计出来的东西能保证高性能
degrees in physics and applied mathematics", his PhD thesis on "Program
Structure and Computational Complexity" at Harvard.
这批CS先驱都有硬件的底子，研究风格比较实际，设计出来的东西能保证高性能
相关阅读
请问一下做应用软件应该做成desktop GUI还是web service 更好， 那个是将来的发展趋势？Miners Are Learning to Codeweb.xmlPandas DataFrame: how to plot candlestick with datetime xlabels?TIOBE Index for February 2016快速系统学习 c++ design pattern有什么好书或者网站吗Ecosystem最重要，语言是其次围棋人机大战细则出炉 李世石最多拿到125万美元哪里能看到比较流行的技术请教 怎么实现保存搜索结果的URL求问个C# gc的问题angular2真是装b，搞得太复杂。为什么你们都歧视阿三呢？我认识的印度女生都听温柔的 (转载)Pinterest的开源deploy系统:Teletraan发个面试题Corel WordPerfect Office为啥还活着？问几个神经网络的问题物理学发展停滞，元凶是cs行业的毒害 (转载)Telerik给我发了个优惠价邮件。还是我那句话，不作不死