Here are some totally unscientific definitions, use at your own risk:
Static typing: Both variables and objects have types. Type checking happens both at compile time and run time.
Dynamic typing: Variables don't have types, but objects do. Type checking happens at run time.
Strong typing: Strict and effective type checks; a string is a string and not a number. Often confused with static typing.
Weak typing: Absent or ineffective type checks. E.g.: everything is a string, or everything is a pointer. Thus, a string could be used as a number or the other way round. Often confused with dynamic typing.
Python, for example, has strong but dynamic typing.
BTW, if you haven't seriously tried a dynamically typed language yet, maybe you should - they are simply much more fun, IMHO.
For Java, the three most prominent GUI libraries are AWT, Swing and SWT. Though I'm not an expert, here's what I understand of their differences.
AWT was Sun's first attempt, what you see in applets and early apps. AWT uses Java proxies for native widgets, but suffers from the "lowest common denominator" problem - it only offers a small number of widgets available on all platforms. Supposedly, it had to be developed in a hurry because of a requirement from Netscape (remember them?), and it shows. AWT is available in most built-in browser VMs, and it's not so large to learn.
Swing is Sun's replacement for AWT (which, AFAIK, is still supported but not being significantly enhanced). To avoid the problems with AWT, with Swing the pendulum is now, uhm, moving in the other direction: Swing uses graphics primitives to draw it's own widgets. So, they were able to provide a lot of them, and they really look the same on all platforms, with a set of different looks to choose from ("pluggable look and feel"). Swing has a reputation for being slow, but with current VMs and on non-ancient computers, IMHO that is no longer true. The Swing API is better designed than AWT, but large.
When the guys at IBM developed Eclipse (GREAT IDE, now open source, see www.eclipse.org), they wanted it to be competitive with the GUIs of Microsoft's IDEs, which Swing wasn't back then. So they rolled their own, SWT, which is also available as open source. I only know it as a user and having read a little, but from what I understand, they use native widgets where possible, but draw their own where the target platform lacks a specific widget, and thus avoid AWTs lowest-common-denominator problems. Because of the native widgets, and judging from Eclipse, SWT apps feel snappier and much more native (like real GTK2/Motif/XP/...) than Swing apps. I heard SWT has its own problems, among them it's not being part of Java's standard libraries, but I don't know enough about those to talk about them - here you will have to do your own research.
Make a comparison table between both languages, listing similarities and differences, and features which exist only in one or the other language. This way, when you think about both languages in terms of differences, you are less likely to mix them up, but at the same time, best leverage similarities in your learning.
Trying to create a good structure for that table is probable alone going to give you some insights into the structure of programming languages!
When you're done, be nice and put your table up somewhere on the web, might be helpful for anyone coming from COBOL wanting to learn VB or the other way round. One never knows.
Prototyping in java and moving to python won't be bad since you can develop in either relatively quickly.
I disagree there. Python is much better suited to prototyping than Java, for two reasons:
As GvR correctly says, there's simply more text to type in Java, to a large part because of the overhead of Java's static typing (aka "keeping the compiler happy"), but also because Python is slightly more high-level than Java.
The Python code will be much more malleable and easy to change around and refactor, for the same reason that you won't have to adapt all your type declarations to keep the compiler happy. On the other hand, all those declarations that make the Java solution harder to change, are the exact same thing that makes it more robust for large programs / team development. You can't have it both ways.
There's two kinds of prototyping: Evolutionary and exploratory.
In evolutionary prototyping you develop a quick but not so dirty small version of the program (release early and all that), and then keep refactoring it to improve design, and keep tuning it to improve performance, while adding features. Python + Swig + C for performance-critical parts is, as you say, a good combination for that.
In exploratory prototyping, you first quickly hack out one version of your program to learn about the user's real requirements, demo it to investors, find out about the consequences of architectural choices and so on. When you know what you want, and that it's worth the effort/money, you throw away your prototype and start work on an industrial-strength solution. Prototype in Python, final implementation in Java would be a "modern" combination for that.
That's why the Java comment is not out of context.
It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?
Yes. When not using MVC, you might well have to recode it 3 times.:)
Besides, you can do MVC in PHP / Perl, and you can code quick and dirty in Java.
Well, don't use KDE or Gnome then, try XFCE or WindowMaker.
An intro that actually introduces would be helpful
on
Fresco M1 Released
·
· Score: 4, Informative
Really, half a sentence of what this Fresco is about would have been helpful in the introduction - e.g. "Fresco is a windowing system derived from a powerful structured graphics toolkit" (from the page). This would save readers not familiar with the project from having to click on the article to find out whether it interests them, and it would reduce the slashdot effect a bit.
I know, it's a novel concept, an introduction actually introducing the readers to the subject...
Insightful?! This completely misses the topic at hand! The problem wasn't about Microsoft not giving support for a modded XBox, it's about Microsoft actively shutting down their network services for such a box, forever. Quite a difference, I'd say...
Reading the article, I get the feeling that Joel has gotten used to more leakiness in his tools (Visual Basic, MFC, C++ AFAIK) than he should have. Let me explain:
Consider two imaginary libraries: Really Nice Library (RNL) and Mostly Crufty Functions (MCF).
Both expose some unavoidable leakiness when a) the abstractions don't fit your problem, or the really *is* at that lower level, or b) you are forced to consider the performance characteristics of the lower level, which the abstractions cannot hide.
In addition to that, MCF adds some more leakiness of its own: buggy implementation, bad assumptions, a badly designed interface, common cases not covered by abstractions etc. etc.
When there's leakiness of the first kind, Joel is right: the programmer should be capable of solving the problem at the lower level (and the tools should make it easy for him to do so).
But when you keep experiencing a lot of leakiness of the second kind, maybe you should go looking for a better set of tools. Life's just too short...
Re:Next Up in the Obvious Category...
on
Design Patterns
·
· Score: 2
I guess it's a repositioning of "Slashdot: News for Nerds" to "Slashdot: Stuff for People."
I'm just glad they have their target market so well defined.
Already, Vazquez de Miguel said, more than 10,000 desktop machines have been switched, with 100,000 more scheduled for conversion in the next year. [...] Organizers called their version "Linex," combining the names of Linux and Extremadura. The software has become so popular that it has been downloaded more than 55,000 times from www.linex.org by people outside Extremadura.
This is a bit different in orders of magnitude from just "somebody installing Linux", isn't it?
So, C is more abstract than LISP? And C# is more abstract than Haskell?
Right - high-level languages such as LISP have been in existance for a long time. Mostly just in the research community, though.
On the other, look at the "mainstream" languages that get chosen most often in a business context. Compared to COBOL / FORTRAN, (even) Java and Perl represent progress...
"Higher abstraction" for a programming language means it's farther away from the requirements and constraints of the cpu, and closer to the problem domain.
cpu ------> abstraction ------> problem
As a result, the more abstract language is often less efficient for the computer to execute, but allows the programmer to describe the problem to the computer faster. That is, it makes him more productive, in the sense of...
productivity = features developed / times spent
Now,
the amount of functionality expected of a program keeps rising and rising,
the cost of spending additional cpu cycles on more abstraction keeps going down and down,
programmer time stays at (very roughly) the same price.
As a result, the "sweet spot" in the tradeoff between programmer time and cpu cycles now is with more abstract languages than it was 10 years ago. This is also why in the past the abstraction level of "mainstream" languages has steadily increased (machine language -> assembler -> macro assembler -> COBOL/FORTRAN -> modular/structured languages -> object-oriented languages).
This is also why I firmly believe the abstraction level will keep going up, through stuff like:
stronger influence of functional abstractions on mainstream languages (e.g. having closures and higher-order functions)
support for "stronger" abstractions through features such as design by contract, aspect-oriented programming, generics etc.
I also expect more new languages to have dynamic instead of static typing, which is also a way to attain higher programmer productivity (especially for refactoring) at the cost of compiler/runtime efficiency.
One more note: Before you argue against higher abstraction, please check if your line of reasoning could have been used as an argument for assembler and against higher-level languages. If so, maybe something is wrong with it...
But don't they say "follow your bliss"? If you get off on learning about new and exciting Debian packages, isn't that just as valid (for you) as sex is for someone who gets off on sex?
You could try it out sometime, and then tell us about it: "Debian and Sex Compared - The big review for those who know only one or the other."
To be honest, many of the recent slashdot posts require the reader to think exactly like the writers did in order to understand the sentences properly. Otherwise, most of them require a bit of unnecessary reading and re-reading to get their meaning right.
It's stable and intuitive without the use my way and like it that redhat tends towards or the I work great if I decide to work of mandrake.
For example, why did it take me almost 3 tries to hack my way through the previous sentence? Complete punctuation and grammar are standard technologies now, you should be able to use them. Thanks!
Slashdot Mirror
[...] weak typing places much more load on the programmer [...] The result is many more bugs
Let me guess: This is what your professor told you?
Try it out sometime, you might find that neither is true in practice.
Here are some totally unscientific definitions, use at your own risk:
Static typing: Both variables and objects have types. Type checking happens both at compile time and run time.
Dynamic typing: Variables don't have types, but objects do. Type checking happens at run time.
Strong typing: Strict and effective type checks; a string is a string and not a number. Often confused with static typing.
Weak typing: Absent or ineffective type checks. E.g.: everything is a string, or everything is a pointer. Thus, a string could be used as a number or the other way round. Often confused with dynamic typing.
Python, for example, has strong but dynamic typing.
BTW, if you haven't seriously tried a dynamically typed language yet, maybe you should - they are simply much more fun, IMHO.
Dynamic typing might well be superior in practice, but it could never work in theory!
For Java, the three most prominent GUI libraries are AWT, Swing and SWT. Though I'm not an expert, here's what I understand of their differences.
AWT was Sun's first attempt, what you see in applets and early apps. AWT uses Java proxies for native widgets, but suffers from the "lowest common denominator" problem - it only offers a small number of widgets available on all platforms. Supposedly, it had to be developed in a hurry because of a requirement from Netscape (remember them?), and it shows. AWT is available in most built-in browser VMs, and it's not so large to learn.
Swing is Sun's replacement for AWT (which, AFAIK, is still supported but not being significantly enhanced). To avoid the problems with AWT, with Swing the pendulum is now, uhm, moving in the other direction: Swing uses graphics primitives to draw it's own widgets. So, they were able to provide a lot of them, and they really look the same on all platforms, with a set of different looks to choose from ("pluggable look and feel"). Swing has a reputation for being slow, but with current VMs and on non-ancient computers, IMHO that is no longer true. The Swing API is better designed than AWT, but large.
When the guys at IBM developed Eclipse (GREAT IDE, now open source, see www.eclipse.org), they wanted it to be competitive with the GUIs of Microsoft's IDEs, which Swing wasn't back then. So they rolled their own, SWT, which is also available as open source. I only know it as a user and having read a little, but from what I understand, they use native widgets where possible, but draw their own where the target platform lacks a specific widget, and thus avoid AWTs lowest-common-denominator problems. Because of the native widgets, and judging from Eclipse, SWT apps feel snappier and much more native (like real GTK2/Motif/XP/...) than Swing apps. I heard SWT has its own problems, among them it's not being part of Java's standard libraries, but I don't know enough about those to talk about them - here you will have to do your own research.
Make a comparison table between both languages, listing similarities and differences, and features which exist only in one or the other language. This way, when you think about both languages in terms of differences, you are less likely to mix them up, but at the same time, best leverage similarities in your learning.
Trying to create a good structure for that table is probable alone going to give you some insights into the structure of programming languages!
When you're done, be nice and put your table up somewhere on the web, might be helpful for anyone coming from COBOL wanting to learn VB or the other way round. One never knows.
I disagree there. Python is much better suited to prototyping than Java, for two reasons:
There's two kinds of prototyping: Evolutionary and exploratory.
In evolutionary prototyping you develop a quick but not so dirty small version of the program (release early and all that), and then keep refactoring it to improve design, and keep tuning it to improve performance, while adding features. Python + Swig + C for performance-critical parts is, as you say, a good combination for that.
In exploratory prototyping, you first quickly hack out one version of your program to learn about the user's real requirements, demo it to investors, find out about the consequences of architectural choices and so on. When you know what you want, and that it's worth the effort/money, you throw away your prototype and start work on an industrial-strength solution. Prototype in Python, final implementation in Java would be a "modern" combination for that.
That's why the Java comment is not out of context.
other examples are software programming where C++ can be the best solution for developing algorithms, and VB for simple DB connected user interfaces
You don't know a lot of languages, do you?
s/Everquest/Slashdot/g
It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?
:)
Yes. When not using MVC, you might well have to recode it 3 times.
Besides, you can do MVC in PHP / Perl, and you can code quick and dirty in Java.
Well, don't use KDE or Gnome then, try XFCE or WindowMaker.
Really, half a sentence of what this Fresco is about would have been helpful in the introduction - e.g. "Fresco is a windowing system derived from a powerful structured graphics toolkit" (from the page). This would save readers not familiar with the project from having to click on the article to find out whether it interests them, and it would reduce the slashdot effect a bit.
I know, it's a novel concept, an introduction actually introducing the readers to the subject...
Insightful?! This completely misses the topic at hand! The problem wasn't about Microsoft not giving support for a modded XBox, it's about Microsoft actively shutting down their network services for such a box, forever. Quite a difference, I'd say...
Reading the article, I get the feeling that Joel has gotten used to more leakiness in his tools (Visual Basic, MFC, C++ AFAIK) than he should have. Let me explain:
Consider two imaginary libraries: Really Nice Library (RNL) and Mostly Crufty Functions (MCF).
Both expose some unavoidable leakiness when a) the abstractions don't fit your problem, or the really *is* at that lower level, or b) you are forced to consider the performance characteristics of the lower level, which the abstractions cannot hide.
In addition to that, MCF adds some more leakiness of its own: buggy implementation, bad assumptions, a badly designed interface, common cases not covered by abstractions etc. etc.
When there's leakiness of the first kind, Joel is right: the programmer should be capable of solving the problem at the lower level (and the tools should make it easy for him to do so).
But when you keep experiencing a lot of leakiness of the second kind, maybe you should go looking for a better set of tools. Life's just too short...
I guess it's a repositioning of "Slashdot: News for Nerds" to "Slashdot: Stuff for People."
I'm just glad they have their target market so well defined.
You obviously didn't read the article.
Already, Vazquez de Miguel said, more than 10,000 desktop machines have been switched, with 100,000 more scheduled for conversion in the next year. [...] Organizers called their version "Linex," combining the names of Linux and Extremadura. The software has become so popular that it has been downloaded more than 55,000 times from www.linex.org by people outside Extremadura.
This is a bit different in orders of magnitude from just "somebody installing Linux", isn't it?
TealScript is a hack that already does what you want, have a look at http://www.tealpoint.com/software.htm
So, C is more abstract than LISP? And C# is more abstract than Haskell?
Right - high-level languages such as LISP have been in existance for a long time. Mostly just in the research community, though.
On the other, look at the "mainstream" languages that get chosen most often in a business context. Compared to COBOL / FORTRAN, (even) Java and Perl represent progress...
cpu ------> abstraction ------> problem
As a result, the more abstract language is often less efficient for the computer to execute, but allows the programmer to describe the problem to the computer faster. That is, it makes him more productive, in the sense of...
productivity = features developed / times spent
Now,
As a result, the "sweet spot" in the tradeoff between programmer time and cpu cycles now is with more abstract languages than it was 10 years ago.
This is also why in the past the abstraction level of "mainstream" languages has steadily increased (machine language -> assembler -> macro assembler -> COBOL/FORTRAN -> modular/structured languages -> object-oriented languages).
This is also why I firmly believe the abstraction level will keep going up, through stuff like:
I also expect more new languages to have dynamic instead of static typing, which is also a way to attain higher programmer productivity (especially for refactoring) at the cost of compiler/runtime efficiency.
One more note: Before you argue against higher abstraction, please check if your line of reasoning could have been used as an argument for assembler and against higher-level languages. If so, maybe something is wrong with it...
You could try it out sometime, and then tell us about it: "Debian and Sex Compared - The big review for those who know only one or the other."
It's sure to be featured on Slashdot.
Let's give this new site a warm welcome. Everybody please click on the link to it and then reload a few times, thank you.
To be honest, many of the recent slashdot posts require the reader to think exactly like the writers did in order to understand the sentences properly. Otherwise, most of them require a bit of unnecessary reading and re-reading to get their meaning right.
It's stable and intuitive without the use my way and like it that redhat tends towards or the I work great if I decide to work of mandrake.
For example, why did it take me almost 3 tries to hack my way through the previous sentence? Complete punctuation and grammar are standard technologies now, you should be able to use them. Thanks!
"Kramnik was never worried about losing..." out of context is a bit misleading: Kramnik didn't win either, it was just a draw.
;) )
(For those who don't read the articles...
The applications I spent most of my time in and which I like best are:
- Eclipse (fully Java, SWT GUI)
- Mozilla (can run Java with Plugin)
- TogetherJ (fully Java, Swing GUI).
So for me, at least, Java is doing just fine on the client, tank you.
Sorry to inform you, dear customer, but your mail seems to have been misdirected. It's clearly addressed at AOL, but this here is Slashdot... ;)