What happened to software? Why is there so few creative software (2010)? Are we at the end of software? What are the forces which led to this situation, looking like a bit step backward to the epoch of non-programmable accounting machines? Is there a way out of this situation? Yes, and a very simple one: make good software. With invention. Developing models and abstractions. It is difficult but absolutely possible. It this re-start of software I wish to explore here in this blog. Welcome
domingo, 14 de julho de 2013
domingo, 7 de julho de 2013
2 news from my friend Teca
sexta-feira, 5 de julho de 2013
About COBOL
Banks will stick with COBOL because Java has performance issues, claims quality guru Bill Curtis: He shows real reasons of Cobol continuity. Nothing to do with the language. It is the maturity time for programs, the quality of programmers, the Web.
Also: Java apps have most flaws, Cobol apps the least, study finds
Also: Java apps have most flaws, Cobol apps the least, study finds
domingo, 19 de maio de 2013
More on first programming language
William Cusing post in the ResearchGate discussion on which programming language to use in a first programming course. Very interessting:
Racket is a variant of Scheme that focuses on teaching.
http://htdp.org/
http://docs.racket-lang.org/ drracket/htdp-langs.html
The Structure and Interpretation of Computer Programs (SICP) is also a classic textbook in computer science (which also teaches Scheme).
Teaching someone a language is a serious amount of responsibility. It amounts to teaching how to think. Teaching a low-level machine language will 'straightjacket' that individual into low-level thinking. That could be called inflicting brain damage (eminent computer scientists do say so -- such as Dijkstra), instead of teaching.
It is rare, and only will get rarer as compilers/interpreters/ virtual-machines
improve, that programmers are needed to produce fast programs nowadays.
Optimizing before profiling is the root of project failure. Learning
how to think at a higher level, profile, and optimize by hand only when
truly necessary is the way to approach the present, and moreso the
future.
For example, let's consider a typical domain where C is held to be the "best" language: numerical algorithms. Say Fast Fourier Transform. Please Read:http://en.wikipedia.org/wiki/ FFTW
http://www.fftw.org/faq/ section2.html#languages
In particular note that the Fastest Fourier Transform is implemented in a combination of ML and OCaml. They wrote their own mini-compiler in those languages, that spits out C code better than anyone else's hand-written C code. They pulled that off because ML and OCaml allow them to easily write their own compiler customized to compiling Fast Fourier Transforms.
In 'principle' they could have written C code to manipulate C code; but in reality such a project would have failed. Likewise, in 'principle' we could implement an OS in assembly: but the result would be horribly poor in features, if it worked at all. From such considerations it should become clear: the path to the future is higher level languages. C is the new assembly (and has been for some time). Learn it only for the purpose of compiling to it (or because you have a burning desire to implement device drivers for the rest of your life), and learn it only after learning one of the many superior higher level languages out there.
It is important to learn a higher level language first (ML, OCaml, Python, Ruby, Scala, Clojure, Scheme, Racket, Common LISP, ...) so that you do (less) harm to your ability to think clearly and concisely. Of these languages, Scheme has probably the best support for teaching, and one of the purest approaches; it may not be the language you use on a daily basis for the rest of your life, but it is an ideal language to have learned first.
An my answer, below:
I think there is a prejudice against low-level languages. If you think about it, Assembly or machine-level language is not "low level". It is very detailed, indeed. But a few syntactic sugar + expression parsing can take care of the register-to-memory and memory-to-register operations. There are languages, like old PL360, which do that. You can write complete expressions and the languages translates them to machine-language.
So, the point is not being low level. Also not of being a machine language. We had high level machine language like Algol for the Burroughs machine, or LISP for the Symbolic Machines.
The point is that learning machine language we do learn a Universal Machine model. The Von Neumann model. This experience is enlightning. The student understands that data and program have the same representation, are stored in the same memory. The student catches what a compiler has to do to translate his "high level program".
Lisp, Scheme or Racket, as mentioned in William Cushing post, and used in SICP, teach yet another different Universal Machine model, the lambda calculus.
With the Universal Machine concepts understood, the student can then go to "standard" programming languages like C, Java, etc...
Racket is a variant of Scheme that focuses on teaching.
http://htdp.org/
http://docs.racket-lang.org/
The Structure and Interpretation of Computer Programs (SICP) is also a classic textbook in computer science (which also teaches Scheme).
Teaching someone a language is a serious amount of responsibility. It amounts to teaching how to think. Teaching a low-level machine language will 'straightjacket' that individual into low-level thinking. That could be called inflicting brain damage (eminent computer scientists do say so -- such as Dijkstra), instead of teaching.
It is rare, and only will get rarer as compilers/interpreters/
For example, let's consider a typical domain where C is held to be the "best" language: numerical algorithms. Say Fast Fourier Transform. Please Read:http://en.wikipedia.org/wiki/
http://www.fftw.org/faq/
In particular note that the Fastest Fourier Transform is implemented in a combination of ML and OCaml. They wrote their own mini-compiler in those languages, that spits out C code better than anyone else's hand-written C code. They pulled that off because ML and OCaml allow them to easily write their own compiler customized to compiling Fast Fourier Transforms.
In 'principle' they could have written C code to manipulate C code; but in reality such a project would have failed. Likewise, in 'principle' we could implement an OS in assembly: but the result would be horribly poor in features, if it worked at all. From such considerations it should become clear: the path to the future is higher level languages. C is the new assembly (and has been for some time). Learn it only for the purpose of compiling to it (or because you have a burning desire to implement device drivers for the rest of your life), and learn it only after learning one of the many superior higher level languages out there.
It is important to learn a higher level language first (ML, OCaml, Python, Ruby, Scala, Clojure, Scheme, Racket, Common LISP, ...) so that you do (less) harm to your ability to think clearly and concisely. Of these languages, Scheme has probably the best support for teaching, and one of the purest approaches; it may not be the language you use on a daily basis for the rest of your life, but it is an ideal language to have learned first.
An my answer, below:
I think there is a prejudice against low-level languages. If you think about it, Assembly or machine-level language is not "low level". It is very detailed, indeed. But a few syntactic sugar + expression parsing can take care of the register-to-memory and memory-to-register operations. There are languages, like old PL360, which do that. You can write complete expressions and the languages translates them to machine-language.
So, the point is not being low level. Also not of being a machine language. We had high level machine language like Algol for the Burroughs machine, or LISP for the Symbolic Machines.
The point is that learning machine language we do learn a Universal Machine model. The Von Neumann model. This experience is enlightning. The student understands that data and program have the same representation, are stored in the same memory. The student catches what a compiler has to do to translate his "high level program".
Lisp, Scheme or Racket, as mentioned in William Cushing post, and used in SICP, teach yet another different Universal Machine model, the lambda calculus.
With the Universal Machine concepts understood, the student can then go to "standard" programming languages like C, Java, etc...
sábado, 18 de maio de 2013
5 pioneering paths for software development's new frontier
Beware of the complexity in the development environment. Question: how to keep it simple? And efficient.
quinta-feira, 16 de maio de 2013
How to write bad software
Culture of the enterprise, lots of money invested, no strong drive, etc... see: "I Contribute to the Windows Kernel. We Are Slower Than Other Operating Systems. Here Is Why."
Assinar:
Postagens (Atom)