Gee a topic about which I can speak with authority.
Japanese is the easiest language to learn. Also the hardest.
The grammar is extraordinarily simple. You can learn most of the basic grammar you need in a few weeks of intensive memorization.
Pronunciation is so easy for an English speaker you hardly even have to work at it.
Vocab works the way English works: combine some parts to make a whole. So once you learn a core set of words you can generate new ones relatively easily.
The writing system is extraordinarily difficult. Kana - you can memorize the entire hiragana/katakana system in a day if you really want to. But kanji! Count on spending years working at it.
Colloquial, socially appropriate speech - extraordinarily difficult. You can get the basic concepts from a book or class, but this level you can only really learn in-country, from native-speaker informants, and even then you may not get it completely.
In sum, you can learn enough J to communicate effectively verbally, and to understand manga, etc. pretty easily. Practical advice: find a Japanese bookstore or website - I'd bet there's more good printed material for students of J than for any other language. Memorize, memorize, memorize, and actually make the sounds. And find a native speaker to help you. And don't be intimidated. And don't waste your time if you're not serious about it. And if you _really_ want to learn the language, plan on a stay in Japan of at least one year. There's no other way to do it.
(I've studied J for years, Japanese wife, etc. but gave up trying to really master it since I've not lived in Japan. If you want to try a *truly* difficult language, try Arabic. I'm pretty fluent - 2+ years in Egypt, not enough. *Everything* about Arabic is *very* difficult. Makes Japanese look like a walk in the park.)
Absolutely agree! But I quibble about the "easy and fun" part; I find Z to be remarkably clear, simple, and concise, and fun to use, precisely because it helps one to think at a high level of abstraction. Use it a bit and you will see much more clearly the artistry involved in writing texts in formal languages (i.e. programming). It's all about manipulation of form, like any art.
You can write all the unit and system tests you want, but you'll never get better than "passes the tests we wrote!", so the best you can do is give some sort of vague estimate of the *probability* that the stuff won't crash and is correct. But if you use formal methods like Z you can prove mathematically that your specification is consistent and bug free. (Note: that doesn't mean it models the problem correctly.) Then implement using a functional language like SML or Haskell and you get more provability. Contrary to some assertions on this thread, it is indeed possible to write programs that will never crash - all you have to do is use a good (typed) FP language.
All the sincere advice about how to code and test bugless code is useful if you have no choice but to work in stone-age conditions. But why not let the computer handle stuff like that? Then you can focus on the real task, which is correctly modeling a real-world problem.
"I need to create an ultra-stable, crash-free application in C++. Sadly, the programming language cannot be changed due to reasons of efficiency and availability of core libraries." Those are bogus reasons. Presumably the system has certain performance and stability requirements that must be met. Implementation language is not relevant, so long as those requirements are met. There are many ways to meet such requirements regardless of language.
If you want "ultra-stability", then choose a language designed for that purpose. Standard ML is the obvious choice - why waste time testing when you can prove the correctness of the program from the get-go?
"Availability of core libraries" - what relevance does this have? It's pretty standard practice these days for languages to provide access to external libraries, regardless of implementation language.
Once you have a provably correct and therefore "ultra-stable" implementation, attack the performance issues. Profile to find the bottlenecks. Use better algorithms. Recode performance hogging functions in assembly. Most obviously, upgrade the hardware. It's much cheaper and practically risk-free.
Re:Emacs is nice, but conceptually dated...
on
The Future of Emacs
·
· Score: 1
Ditto. Believe it or not, I even use (nt-)Emacs to browse/edit Arabic text. Because it uses the MS text drawing engine, the individual words are correctly shaped and read right-to-left. But the lines run left-to-right. Takes a little practice, but now I can use all emacs functionality to work on Arabic text.
With the right font, it's also easy to use Unicode symbols (e.g. from the Arrows, Math, Technical, etc. blocks of Unicode) in emacs.
I wouldn't bet on that:
http://developers.sun.com/prodtech/javatools/jsent erprise/index.html
Anyway, different tools for different purposes. Emacs (or vi) will always be the tool of choise for individuals doing system-level c programming (among other things), but for corporate teams developing enterprise-class business applications, emacs probably isn't even an option; both Eclipse and Sun's Java Studio will see plenty of use. Not to mention other environments. The more the merrier.
Hello? Haven't you heard? Company loyalty died sometime in the 80's. Always, *always* think of yourself as an independent professional in a business relationship with a client, even if you are a long-term employee. My personal approach is that I hire my employer as much as they hire me. It makes it easier to think clearly about the interests involved in that relationship and avoid letting emotion get in the way. (It also makes job interviews much easier.) Companies (especially big ones) are practically obligated to act as they did in your case, for very good business reasons. No employer owes you anything; you don't owe them anything. You simply exchange value - work for money - under agreed-upon terms. So the next time you terminate your business relationship with a client (resign from a company), get your ducks in a row before you notify them. Meaning, make sure that you no longer have any need to access company resources, and you won't be surprised or upset if the security guard escorts you to the door immediately. *Then* give them a professional two weeks notice. Also, don't forget that your point of contact with the client - your boss - is a human with ambitions etc. in the context of a corporate career. Don't take any reaction personally - it's just business, even if the boss tends to forget that (or never knew it).
If you need to make high level node-arc diagrams of the structure of a site, take a look at GraphViz (http://www.graphviz.org/) It's very powerful, with a very simple text syntax, and saves you the trouble of manually routing the arcs. You might also want to take a look at Asymptote (http://asymptote.sourceforge.net/)
If you haven't looked into XUL it's well worth the effort. With XUL (i.e. the Mozilla App Platform) there's a real possibility you could respond "Ok" to a request to implement the prototype.
Or you could do what a consulting firm did to, er, for my employer. Buy some Macs, and spend a lot of time using Photoshop etc. to create bitmap images that look like a GUI. Then spend a lot of time making PDF files from the images, showing a UI that looks nothing like a computer GUI, but that in the end will bear some resemblance to the finished product. Be sure to charge a lot of money and call your people "designers", so your client will think he's getting real value for the money. Call the PDF files by some term that sounds like a term of art - they called them "wireframes" on my project - to enhance the illusion that mere mortals could not possibly do the work. Then hire some grunts to look at the PDF files and try to make a GUI that looks like them, sort of. Be sure to make expensive, customized button images, even for stuff like "Yes", "No", etc. Also, make sure you call yourself a "User Experience Specialist" or something like that. No, "User Experience Architect" is better - always try to get "Architect" in your titles, and charge extra for it.
And it's not a "prototype", its a "User Experience architecture preview".
Slashdot Mirror
Gee a topic about which I can speak with authority.
Japanese is the easiest language to learn. Also the hardest.
The grammar is extraordinarily simple. You can learn most of the basic grammar you need in a few weeks of intensive memorization.
Pronunciation is so easy for an English speaker you hardly even have to work at it.
Vocab works the way English works: combine some parts to make a whole. So once you learn a core set of words you can generate new ones relatively easily.
The writing system is extraordinarily difficult. Kana - you can memorize the entire hiragana/katakana system in a day if you really want to. But kanji! Count on spending years working at it.
Colloquial, socially appropriate speech - extraordinarily difficult. You can get the basic concepts from a book or class, but this level you can only really learn in-country, from native-speaker informants, and even then you may not get it completely.
In sum, you can learn enough J to communicate effectively verbally, and to understand manga, etc. pretty easily. Practical advice: find a Japanese bookstore or website - I'd bet there's more good printed material for students of J than for any other language. Memorize, memorize, memorize, and actually make the sounds. And find a native speaker to help you. And don't be intimidated. And don't waste your time if you're not serious about it. And if you _really_ want to learn the language, plan on a stay in Japan of at least one year. There's no other way to do it.
(I've studied J for years, Japanese wife, etc. but gave up trying to really master it since I've not lived in Japan. If you want to try a *truly* difficult language, try Arabic. I'm pretty fluent - 2+ years in Egypt, not enough. *Everything* about Arabic is *very* difficult. Makes Japanese look like a walk in the park.)
good luck.
You can write all the unit and system tests you want, but you'll never get better than "passes the tests we wrote!", so the best you can do is give some sort of vague estimate of the *probability* that the stuff won't crash and is correct. But if you use formal methods like Z you can prove mathematically that your specification is consistent and bug free. (Note: that doesn't mean it models the problem correctly.) Then implement using a functional language like SML or Haskell and you get more provability. Contrary to some assertions on this thread, it is indeed possible to write programs that will never crash - all you have to do is use a good (typed) FP language.
All the sincere advice about how to code and test bugless code is useful if you have no choice but to work in stone-age conditions. But why not let the computer handle stuff like that? Then you can focus on the real task, which is correctly modeling a real-world problem.
If you want "ultra-stability", then choose a language designed for that purpose. Standard ML is the obvious choice - why waste time testing when you can prove the correctness of the program from the get-go?
"Availability of core libraries" - what relevance does this have? It's pretty standard practice these days for languages to provide access to external libraries, regardless of implementation language.
Once you have a provably correct and therefore "ultra-stable" implementation, attack the performance issues. Profile to find the bottlenecks. Use better algorithms. Recode performance hogging functions in assembly. Most obviously, upgrade the hardware. It's much cheaper and practically risk-free.
Ditto. Believe it or not, I even use (nt-)Emacs to browse/edit Arabic text. Because it uses the MS text drawing engine, the individual words are correctly shaped and read right-to-left. But the lines run left-to-right. Takes a little practice, but now I can use all emacs functionality to work on Arabic text. With the right font, it's also easy to use Unicode symbols (e.g. from the Arrows, Math, Technical, etc. blocks of Unicode) in emacs.
I wouldn't bet on that: http://developers.sun.com/prodtech/javatools/jsent erprise/index.html
Anyway, different tools for different purposes. Emacs (or vi) will always be the tool of choise for individuals doing system-level c programming (among other things), but for corporate teams developing enterprise-class business applications, emacs probably isn't even an option; both Eclipse and Sun's Java Studio will see plenty of use. Not to mention other environments. The more the merrier.
Hello? Haven't you heard? Company loyalty died sometime in the 80's. Always, *always* think of yourself as an independent professional in a business relationship with a client, even if you are a long-term employee. My personal approach is that I hire my employer as much as they hire me. It makes it easier to think clearly about the interests involved in that relationship and avoid letting emotion get in the way. (It also makes job interviews much easier.) Companies (especially big ones) are practically obligated to act as they did in your case, for very good business reasons. No employer owes you anything; you don't owe them anything. You simply exchange value - work for money - under agreed-upon terms. So the next time you terminate your business relationship with a client (resign from a company), get your ducks in a row before you notify them. Meaning, make sure that you no longer have any need to access company resources, and you won't be surprised or upset if the security guard escorts you to the door immediately. *Then* give them a professional two weeks notice. Also, don't forget that your point of contact with the client - your boss - is a human with ambitions etc. in the context of a corporate career. Don't take any reaction personally - it's just business, even if the boss tends to forget that (or never knew it).
If you need to make high level node-arc diagrams of the structure of a site, take a look at GraphViz (http://www.graphviz.org/) It's very powerful, with a very simple text syntax, and saves you the trouble of manually routing the arcs. You might also want to take a look at Asymptote (http://asymptote.sourceforge.net/)
If you haven't looked into XUL it's well worth the effort. With XUL (i.e. the Mozilla App Platform) there's a real possibility you could respond "Ok" to a request to implement the prototype.
Or you could do what a consulting firm did to, er, for my employer. Buy some Macs, and spend a lot of time using Photoshop etc. to create bitmap images that look like a GUI. Then spend a lot of time making PDF files from the images, showing a UI that looks nothing like a computer GUI, but that in the end will bear some resemblance to the finished product. Be sure to charge a lot of money and call your people "designers", so your client will think he's getting real value for the money. Call the PDF files by some term that sounds like a term of art - they called them "wireframes" on my project - to enhance the illusion that mere mortals could not possibly do the work. Then hire some grunts to look at the PDF files and try to make a GUI that looks like them, sort of. Be sure to make expensive, customized button images, even for stuff like "Yes", "No", etc. Also, make sure you call yourself a "User Experience Specialist" or something like that. No, "User Experience Architect" is better - always try to get "Architect" in your titles, and charge extra for it.
And it's not a "prototype", its a "User Experience architecture preview".