5 ms·

The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort o

The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Pythonic, but he's wrong to say we'll all write in Python some day. Some day, something like Python will be the fast low level language, there will be new slower languages that are easier to use than Python, and C will be a memory. The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth. I must say though that I pray for more convergence. It annoys me to write code in JavaScript and Python, having to remember subtle differences between the two as small as capitalization of true and False, and tricky pitfalls like the scope of a variable declared in an if block. It does seem an unnecessary burden for me as a web developer to have to know a handful of languages. You can hardly make a website today without knowing HTML, CSS, Javascript, Python/Ruby, and you better know your SQL too. Then, let's talk APIs.

vorador 17y ago
C is portable assembly, I see no reason for it to disappear, and actually it would bother me to have to write low-level stuff in python.
- scott_s 17y ago
  I agree. While some languages go extinct, their domains remain. As we progress in computing and how to express it, we expand the domains that we program in.
Tichy 17y ago
Some people really want static types.
- gaius 17y ago
  More people than you'd think, hence the current fashion for "unit tests".
  - _pius 17y ago
    Static typing hardly replaces unit tests. And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer. If it were true, why would Java programmers use JUnit?
    - stcredzero 17y ago
      As a long time Smalltalker, let me say -- we HLL language guys should get off of our high horse about static typing. Anything that you can do to move bugs from runtime to compile time is good for the maintainer. No, static types don't catch everything. But they are desirable if they catch anything at all. Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.
      - _pius 17y ago
        No, static types don't catch everything. But they are desirable if they catch anything at all. I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too! In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer. I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? Wouldn't you then lose a great deal of the leverage of using a freedom language?
        17y ago
gizmo 17y ago
> The only reason to write in a language like C or Java today (over Python) is speed. Do you really believe that?
- charlesju 17y ago
  What are some other benefits of C or Java over something like Ruby and Python?
  - scott_s 17y ago
    The level of abstraction matches most hardware. Not all code written in C is performance-critical. But sometimes it's still the best choice if your code is directly talking to hardware.
    - jshen 17y ago
      In that case wouldn't you write some components in C and glue it all together with something like ruby?
      - scott_s 17y ago
        Sure, that sounds reasonable. But you've still chosen C to talk to the hardware.
        jshen 17y ago
        If you're using ruby or python you're ultimately using C anyway, right ;)
- callahad 17y ago
  I think it's a reasonable statement, if the following premises are accepted: 1. It is easier and quicker to develop a correct solution in a higher level language than a lower level one. 2. Expressiveness / abstraction come at the cost of time and space efficiency. Thus, if time and space efficiency are not a concern, then the higher level language should be preferred.
tezza 17y ago
"there are a very limited number of applications that require that sort of speed" Plenty of software is not web-based or a cron job for Linux. Java, C# are chosen not just because of speed. You can get vendor support from Sun for their JVM stack. You can (try to) get similar support from Microsoft for .Net stack. Then also there are personal preferences :: . Static Typing can be a key part of how people build complex systems in a way they feel comfortable with. When my team codes that way, may bugs are picked up at compile time versus deploy time. . JVM has really nice remote debugging . JVM is much closer to run-anywhere than Python . JVM exits with hs_err files logged
stcredzero 17y ago
Some day, something like Python will be the fast low level language, there will be new slower languages that are easier to use than Python, and C will be a memory. There are Smalltalks that ditched (in one case all) their "primitive" methods written in C against the VM internals because the JIT compiler turned out to be good enough. (Agents for the all case. VisualWorks also lets much of the Dictionary functionality JIT to machine code with no primitives.) The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth. You forget to mention a big factor: speed of cultural transmission. Considering what Lisp, Smalltalk, Self and other languages have been able to achieve for high level languages, why are we still dealing with poky high level languages like Ruby and Python? A part of it is cultural expectations. We still expect HLL to be an order of magnitude slower, even though that expectation is decades out of date, technologically. (HLL should only be 70-50% slower now.)
- vidarh 17y ago
  We are dealing with "poky" high level languages like Ruby and Python because a lot of us find Lisp, Smalltalk and Self horrendous to work with. Ruby in particular is basically Smalltalk + Lisp for regular people - it's taken a good chunk of the concepts and packaged it in a way more people are happy to work with. First time I read about Scheme I was fascinated. Until I played with it a while and put it away and promptly went back to lower level languages (C, Pascal and M68k assembler at the time) because the syntax (or lack of ...) was just too alien for me. Same with Smalltalk. Yes, I discarded them over syntax. Speed never entered the equation - I dropped them before I got to evaluate performance. Ruby is the first language I've worked with that could do justice to a lot of the concepts from Smalltalk and Lisp. I very much doubt Lisp and Smalltalk has much hope of wider use than they see now - most of the important features are being added to other languages, and the remaining ones are not seen as useful enough by most developers to be worth the painful syntax. The computational models and the work done on compiling them efficiently will contribute a lot though. Most Ruby implementations in the work and several Javascript implementations are all over PIC's and other concepts take from the Self project, for example.
  - 17y ago
fauigerzigerk 17y ago
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed You probably mean a very limited number of web app frontend code. That may be true. But I think you underestimate what is being done with software. With a language that is 200 times slower than C or Java you can't do any data analysis, graphics or image processing, machine learning, algorithmic optimisation, financial software like trading, pricing and risk management, embedded systems, bioinformatics, simulation and a whole lot more. You're basically excluding yourself from doing anything that mankind couldn't do before. Progress it's called. Most AI tasks require massive computational power. But even just things like pickling a Python object is too onerous for Python itself. I don't think that's good enough.
- DannoHung 17y ago
  Can we at least all agree that no one should be writing anything in a shell scripting language any longer? I'd be happy with just winning that battle.
  - tsuraan 17y ago
    I like scripting my shell using a shell scripting langauge; if I have a few dozen (or hundred) console operations that need to be done often, then a shell script is more concise than ruby. If I need to add error handling, exceptions, networking, etc, then it's time to move up, but if all that's needed are external programs and some looping and conditionals, then I don't see any problem with scripting.
  - vorador 17y ago
    Why are you against shell scripting languages ?
    - DannoHung 17y ago
      Because I have seen the horrors that they wreak in a production system where they are responsible for mission critical logic. The horror. The horror.
rbanffy 17y ago
"There's no question that Linux should be written in a low level language" In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language. I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly. Smalltalk/80 and the various Lisp machines are sufficient proof whole environments, from kernel to GUI, can be written in higher-than-C-level languages, provided the machine is fast enough. If we can extract speed from compilers and not from expensive silicon, I see no reason not to do it. In a couple days I will attend to a lecture on porting the Squeak VM to FPGAs and running Smalltalk on silicon. That should be interesting.
- malkia 17y ago
  But those machines (Smalltalk, Lisp) had dedicated HW dealing with gc, special instructions, etc.
  - stcredzero 17y ago
    I remember being a fly on the wall at a discussion between several very smart VM guys at Camp Smalltalk maybe 7 or 8 years ago. (VisualWorks, Smalltalk/X, Smalltalk Agents, Squeak, Dolphin.) Apparently, there's a lot of stuff chip makers could put in to general-purpose processors to generically support High Level languages. I think it's high time we had some of this, given the prevalence of Java, Perl, Python, Ruby, PHP (yes, it would benefit them too).
- rbanffy 17y ago
  Cannot edit, but I left the link to the presentation out: http://fisl.vidanerd.com/palestra/30 http://fisl.vidanerd.com/palestra/30
deleted 17y ago
[deleted]
agazso 17y ago
You seem to completely ignore the fact that there are environments where speed does not matter, but memory is constrained. In those environments even Java is prohibited and C/C++ or even assembly is a way to go, because in these languages you have direct control over memory allocation.

vorador 17y ago

C is portable assembly, I see no reason for it to disappear, and actually it would bother me to have to write low-level stuff in python.

scott_s 17y ago
I agree. While some languages go extinct, their domains remain. As we progress in computing and how to express it, we expand the domains that we program in.

Tichy 17y ago

Some people really want static types.

gaius 17y ago
More people than you'd think, hence the current fashion for "unit tests".
- _pius 17y ago
  Static typing hardly replaces unit tests. And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer. If it were true, why would Java programmers use JUnit?
  - stcredzero 17y ago
    As a long time Smalltalker, let me say -- we HLL language guys should get off of our high horse about static typing. Anything that you can do to move bugs from runtime to compile time is good for the maintainer. No, static types don't catch everything. But they are desirable if they catch anything at all. Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.
    - _pius 17y ago
      No, static types don't catch everything. But they are desirable if they catch anything at all. I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too! In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer. I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? Wouldn't you then lose a great deal of the leverage of using a freedom language?
      - 17y ago

gizmo 17y ago

> The only reason to write in a language like C or Java today (over Python) is speed. Do you really believe that?

charlesju 17y ago
What are some other benefits of C or Java over something like Ruby and Python?
- scott_s 17y ago
  The level of abstraction matches most hardware. Not all code written in C is performance-critical. But sometimes it's still the best choice if your code is directly talking to hardware.
  - jshen 17y ago
    In that case wouldn't you write some components in C and glue it all together with something like ruby?
    - scott_s 17y ago
      Sure, that sounds reasonable. But you've still chosen C to talk to the hardware.
      - jshen 17y ago
        If you're using ruby or python you're ultimately using C anyway, right ;)
callahad 17y ago
I think it's a reasonable statement, if the following premises are accepted: 1. It is easier and quicker to develop a correct solution in a higher level language than a lower level one. 2. Expressiveness / abstraction come at the cost of time and space efficiency. Thus, if time and space efficiency are not a concern, then the higher level language should be preferred.

tezza 17y ago

"there are a very limited number of applications that require that sort of speed" Plenty of software is not web-based or a cron job for Linux. Java, C# are chosen not just because of speed. You can get vendor support from Sun for their JVM stack. You can (try to) get similar support from Microsoft for .Net stack. Then also there are personal preferences :: . Static Typing can be a key part of how people build complex systems in a way they feel comfortable with. When my team codes that way, may bugs are picked up at compile time versus deploy time. . JVM has really nice remote debugging . JVM is much closer to run-anywhere than Python . JVM exits with hs_err files logged

stcredzero 17y ago

Some day, something like Python will be the fast low level language, there will be new slower languages that are easier to use than Python, and C will be a memory. There are Smalltalks that ditched (in one case all) their "primitive" methods written in C against the VM internals because the JIT compiler turned out to be good enough. (Agents for the all case. VisualWorks also lets much of the Dictionary functionality JIT to machine code with no primitives.) The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth. You forget to mention a big factor: speed of cultural transmission. Considering what Lisp, Smalltalk, Self and other languages have been able to achieve for high level languages, why are we still dealing with poky high level languages like Ruby and Python? A part of it is cultural expectations. We still expect HLL to be an order of magnitude slower, even though that expectation is decades out of date, technologically. (HLL should only be 70-50% slower now.)

vidarh 17y ago
We are dealing with "poky" high level languages like Ruby and Python because a lot of us find Lisp, Smalltalk and Self horrendous to work with. Ruby in particular is basically Smalltalk + Lisp for regular people - it's taken a good chunk of the concepts and packaged it in a way more people are happy to work with. First time I read about Scheme I was fascinated. Until I played with it a while and put it away and promptly went back to lower level languages (C, Pascal and M68k assembler at the time) because the syntax (or lack of ...) was just too alien for me. Same with Smalltalk. Yes, I discarded them over syntax. Speed never entered the equation - I dropped them before I got to evaluate performance. Ruby is the first language I've worked with that could do justice to a lot of the concepts from Smalltalk and Lisp. I very much doubt Lisp and Smalltalk has much hope of wider use than they see now - most of the important features are being added to other languages, and the remaining ones are not seen as useful enough by most developers to be worth the painful syntax. The computational models and the work done on compiling them efficiently will contribute a lot though. Most Ruby implementations in the work and several Javascript implementations are all over PIC's and other concepts take from the Self project, for example.
- 17y ago

fauigerzigerk 17y ago

The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed You probably mean a very limited number of web app frontend code. That may be true. But I think you underestimate what is being done with software. With a language that is 200 times slower than C or Java you can't do any data analysis, graphics or image processing, machine learning, algorithmic optimisation, financial software like trading, pricing and risk management, embedded systems, bioinformatics, simulation and a whole lot more. You're basically excluding yourself from doing anything that mankind couldn't do before. Progress it's called. Most AI tasks require massive computational power. But even just things like pickling a Python object is too onerous for Python itself. I don't think that's good enough.

DannoHung 17y ago
Can we at least all agree that no one should be writing anything in a shell scripting language any longer? I'd be happy with just winning that battle.
- tsuraan 17y ago
  I like scripting my shell using a shell scripting langauge; if I have a few dozen (or hundred) console operations that need to be done often, then a shell script is more concise than ruby. If I need to add error handling, exceptions, networking, etc, then it's time to move up, but if all that's needed are external programs and some looping and conditionals, then I don't see any problem with scripting.
- vorador 17y ago
  Why are you against shell scripting languages ?
  - DannoHung 17y ago
    Because I have seen the horrors that they wreak in a production system where they are responsible for mission critical logic. The horror. The horror.

rbanffy 17y ago

"There's no question that Linux should be written in a low level language" In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language. I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly. Smalltalk/80 and the various Lisp machines are sufficient proof whole environments, from kernel to GUI, can be written in higher-than-C-level languages, provided the machine is fast enough. If we can extract speed from compilers and not from expensive silicon, I see no reason not to do it. In a couple days I will attend to a lecture on porting the Squeak VM to FPGAs and running Smalltalk on silicon. That should be interesting.

malkia 17y ago
But those machines (Smalltalk, Lisp) had dedicated HW dealing with gc, special instructions, etc.
- stcredzero 17y ago
  I remember being a fly on the wall at a discussion between several very smart VM guys at Camp Smalltalk maybe 7 or 8 years ago. (VisualWorks, Smalltalk/X, Smalltalk Agents, Squeak, Dolphin.) Apparently, there's a lot of stuff chip makers could put in to general-purpose processors to generically support High Level languages. I think it's high time we had some of this, given the prevalence of Java, Perl, Python, Ruby, PHP (yes, it would benefit them too).
rbanffy 17y ago
Cannot edit, but I left the link to the presentation out: http://fisl.vidanerd.com/palestra/30 http://fisl.vidanerd.com/palestra/30

deleted 17y ago

[deleted]

agazso 17y ago

You seem to completely ignore the fact that there are environments where speed does not matter, but memory is constrained. In those environments even Java is prohibited and C/C++ or even assembly is a way to go, because in these languages you have direct control over memory allocation.